RE: Force users to use Active DG for reporting

From: McPeak, Matt <>
Date: Wed, 2 Apr 2014 20:57:39 +0000
Message-ID: <>

But, couldn’t you have an on-login trigger to detect whether the user was accessing RW or RO and switch the resource group automatically (or call DBMS_APPLICATION_INFO.SET_MODULE and base your resource group mappings off that)?

From: [] On Behalf Of Andy Wattenhofer Sent: Wednesday, April 02, 2014 1:36 PM To:
Subject: Re: Force users to use Active DG for reporting

Maybe you are referring to resource manager? The two databases are identical, so you can't have different resource plans.


On Wed, Apr 2, 2014 at 12:00 PM, Dba DBA <<>> wrote: I have never done this before, but I think you can use 'resource groups' (that isn't the exact name) and/or profiles to limit how much CPU, etc... sessions can use before they are auto-killed. I have not used this before.

Anyone done this? You may be able to throttle users and this lack of support would force them to go to the standby DB or there reports won't run.

On Mon, Mar 31, 2014 at 11:55 AM, Ricard Martinez <<>> wrote: Hi list,

We got an environment formed by one standalone 11g database (lets call it RW) with an active dataguard on another server (lets call it RO) We have provided to the users 2 tnsnames, one pointing to RW and the other to the RO, and we have told them to use the first one for DML, etc and the RO only for runing the reporting statments.

As good users, they just ignore us and run all on the RW database, so we want to force them to use the RO for reporting. Meanwhile they got the 2 tnsnames entries, i see no real options to force them to use the RW, unless we separate the schema in two (one with insert/update, the other only with select), and we kill any session of the select schema on the RO (using a cron maybe, forcing them to use RW to be able to end their reports)

Has any of you found in a similar situation, or can think in other options?



Andy Wattenhofer
Manager, Database Administration
University of Minnesota
-- Received on Wed Apr 02 2014 - 22:57:39 CEST

Original text of this message