To me this sounds much more like an organizational rather than technical barrier. As Ric alluded to, there has to be incentive for them to buy in on the change. You're trying to get the best ROI on this separate instance. Show the business why this is a good idea and get management to fight the battle for you. When it's pushed down from above it's a lot less negotiable.
In the past I've gotten the buy in on enforcement from the management staff by refreshing their memory on the financial and man hour investment they've made in the standby environment and show the impact you're expecting out of the change. In that situation I loosely policed what was run on the standby vs prod. If I notice something killing the main database, or find an outlier on an AWR report, I'd point it out as a defect and mention it'll have to be reworked or moved to the reporting database. The path of least resistance is generally allowing it to run on the reporting instance. Once there, again assess it's impact. If it's still too heavy handed for your taste work with them to tune it. If they've properly instrumented module/action within their code, identification and evidence gathering becomes extremely simple through queries of your ash/awr data. You can also provide reports of what you've identified should run on the reporting database and currently isn't.
This does also put more responsibility on you as you should also insure they have just as consistent access to that instance, provide any additional documentation the developers, and are available to assist in a successful migration. The quicker you build a standardized process to streamline the identification and migration these tasks the better.
On 03/31/2014 10: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?Thanks
-- ------------------------------------------------------------------ This email is intended solely for the use of the addressee and may contain information that is confidential, proprietary, or both. If you receive this email in error please immediately notify the sender and delete the email.. ------------------------------------------------------------------ -- //www.freelists.org/webpage/oracle-l
