Re: Privileges by session

From: Kellyn Pedersen <kjped1313@xxxxxxxxx>
To: nupendra@xxxxxxxxxxx, development@xxxxxxxxxxxxxxxxx
Date: Mon, 11 Jan 2010 11:59:54 -0800 (PST)
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@xxxxxxxxxxxxxxxxx> wrote:


From: Martin Bach <development@xxxxxxxxxxxxxxxxx>
Subject: Re: Privileges by session
To: nupendra@xxxxxxxxxxx
Cc: martin.a.berger@xxxxxxxxx, wblanchard@xxxxxxxxxxxxxxxxxxxx, 
oracle-l@xxxxxxxxxxxxx
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
[...]
--
//www.freelists.org/webpage/oracle-l
Re: Privileges by session

Other related posts:
