Re: Force users to use Active DG for reporting

From: Kim Berg Hansen <>
Date: Wed, 2 Apr 2014 09:53:51 +0200
Message-ID: <>

So basically your users are normally lazy like most people :-) Rather than having two connections and switching back and forth, they prefer just having their RW connection and can't see "what's in it for me to use RO, that's just more trouble and not worth it to me - I'll just keep doing what I always have done, that's easier." Perfectly normal human reaction.

So education - demonstrate that there are more free CPU cycles available on RO and their reporting will go twice as fast (if it does :-)

Make it a game - perhaps you can create some monitoring that shows you resource consumption on RW and RO instances by client IP-address or machine name?
Then you can give a prize to the user that has highest percentage of RO resource consumption compared with RW consumption in a given week? Or maybe rather than individually, give a bonus to the group with the best RO / RW percentage, so peer pressure within the group will kick in? (Well, maybe have to filter the results a bit to avoid users just firing a lot of reporting on the RO without really needing it ;-)

Until you can change the schema and separate reporting app from the rest, I think your best bet is the carrot rather than the stick ;-) Use psychological "tricks" to make users *want* to do it right and use RO for reporting.
You cannot often rely on the user thinking of "the best for the company" - humans nature will almost always think of "the best for me..."


Kim Berg Hansen

On Tue, Apr 1, 2014 at 5:49 PM, Ricard Martinez <>wrote:

> Yes, there is only one schema. So they connect to odbc connection RW or RO
> with the same schema, that have the same privileges on both databases (as
> they are primary and dataguard all is replicated between them). So we cant
> prevent them from connecting to the RW as they need to in order to do
> updates/insert.
> We discarded resource limit because it will be up for the same schema in
> primary and dataguard, so will prevent running reports on both databases.
> The brute force kill is what we had though already, but is not very clean,
> so just checking for more ideas before implementing it.
> Thanks again guys!

Received on Wed Apr 02 2014 - 09:53:51 CEST

Original text of this message