Re: Force users to use Active DG for reporting
- From: Kim Berg Hansen <kibeha@xxxxxxxxx>
- To: ricard.martinez@xxxxxxxxx
- Date: Wed, 2 Apr 2014 09:53:51 +0200
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..."
Regards
Kim Berg Hansen
http://dspsd.blogspot.com
kibeha@xxxxxxxxx
@kibeha
On Tue, Apr 1, 2014 at 5:49 PM, Ricard Martinez
<ricard.martinez@xxxxxxxxx>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!
>
>
Other related posts:
