Re: Privileges by session
Date: Mon, 11 Jan 2010 11:59:54 -0800 (PST)
Message-ID: <220426.19386.qm_at_web32005.mail.mud.yahoo.com>
I have to agree with Martin on this one, but no matter how much I professionally agree, I know for a fact that there is a large roadblock in the way of this option- Business and Management.
I personally feel my developers are by far my most gifted group, (most developers I work with are simply brilliant, just often a different mindset than DBA's and their vision is aligned differently than ours- it needs to be to perform our jobs...) but are often set up to fail because they:
1. often are not given access to the same dba views that DBA's are privy to that could show them what Oracle is doing "under the covers" by many DBA's I've worked with, (I think we've coved what DBA's those are in the later threads of "What kind of DBA are you?" :)) 2. Have out of date, limited data and/or setup/statistically different database to develop and test in, (as Martin discussed.) 3. Do not have the open communication with their DBA's to be granted success, either by DBA's who aren't able to let them be successful for what they bring to the table or something I find just as detrimental- tell them what the developers WANT to hear instead of telling them what they NEED to hear.
Now how does management make #2 worse? They have a problem seeing the value in buying the hardware to make it happen. Production produces revenue, that's easy to see on a spreadsheet- It's more difficult for them to understand how valuable it is to a company to do things right instead of doing it twice, (or three or more times...) by having development and test environments that are exact duplicates, (at least in data) of production.
When their developers fail because they don't have the systems they need to perform quality work, the management has a tendency to view this as the developer lacking instead of the tools they have provided as lacking.
This is where the DBA's support is imperative. We just recently went through this similar situation at my company and it wasn't until we repeatedly showed in reports that feed deadlines were not being met not because of issues in the production system but performance hits produced by developers querying the system- THEN it was essential for me to follow up by telling my manager that I was not doing my job unless I provided a TRUE copy of production for my developers so they would not have to query production and that I would be failing the company as a DBA if I didn't tell them that.
We are building a new development environment that is a FULL copy of all our production systems in the next month. I've had to go through this exercise at almost every company I've worked at, so it's quite an epedemic. Proving the loss of revenue by not providing the tools developers need is difficult and selling it to management is even a larger challenge. When you haven't overcome this challenge, you are left with developers that DO need to query production, but they have to be sold on the idea that for their own protection, since you don't want them targets when production is impacted, they should utilize their own logins and be in a limited resource groups to ensure they can not.
OK, off my soapbox... :)
Kellyn Pedersen
Multi-Platform DBA
I-Behavior Inc.
http://www.linkedin.com/in/kellynpedersen
"Go away before I replace you with a very small and efficient shell script..."
- On Sun, 1/10/10, Martin Bach <development_at_the-playground.de> wrote:
From: Martin Bach <development_at_the-playground.de>
Subject: Re: Privileges by session
To: nupendra_at_hotmail.com
Cc: martin.a.berger_at_gmail.com, wblanchard_at_societyinsurance.com, oracle-l_at_freelists.org
Date: Sunday, January 10, 2010, 11:01 AM
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 [...] -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Mon Jan 11 2010 - 13:59:54 CST