RE: Privileges by session

  • From: "Barun, Vlado" <Vlado.Barun@xxxxxxx>
  • To: "development@xxxxxxxxxxxxxxxxx" <development@xxxxxxxxxxxxxxxxx>, "nupendra@xxxxxxxxxxx" <nupendra@xxxxxxxxxxx>
  • Date: Mon, 11 Jan 2010 08:17:09 -0500

The prerequisite for your solution is developer cooperation, as the developers 
have to agree to use the replicated environment. 
If my understanding of the situation is correct, this prerequisite does not 
exist.


Vlado Barun, M.Sc., OCE, OCA, MCP
Sr. Database Architect/Manager, Database Engineering and Operations
Jewelry Television
Mobile: 865 335 7652
Email: vlado.barun@xxxxxxx

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Martin Bach
Sent: Sunday, January 10, 2010 1:01 PM
To: nupendra@xxxxxxxxxxx
Cc: martin.a.berger@xxxxxxxxx; wblanchard@xxxxxxxxxxxxxxxxxxxx; 
oracle-l@xxxxxxxxxxxxx
Subject: Re: Privileges by session

Dear list members!

This is a really interesting thread with lots of useful information, but
one important option (IMO) has not yet been mentioned.

If the main reason for allowing developers access to production data is
for them to troubleshoot problems using current data, why don't you use
your favourite replication mechanism such as streams or logical standby
to a separate environment? Developers could use this to their heart's
delight and you can impose your read only restrictions. There shouldn't
be a logical argument against getting them off production with that
approach either.

Any fixes can then be tested against the integration environment before
it's rolled out to production by the DBAs. You could even use a physical
standby to perform this testing: use flashback database or snapshot
standby to activate it and test against current data, then revert it
back to the standby role.

Hope this helps,

Martin
--
Martin Bach
OCM 10g
http://martincarstenbach.wordpress.com

On 09/01/10 00:00, Upendra N wrote:
> In our environment we have software dpkgs are built without the
[...]
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l

Other related posts:

  1. Home
  2. oracle-l
  3. Archive
  4. 01-2010