Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re: V$ access for production support

Re: V$ access for production support

From: <ryan_gaffuri_at_comcast.net>
Date: Mon, 04 Sep 2006 17:22:20 +0000
Message-Id: <090420061722.5025.44FC60CC0001C80F000013A12200758942079D9A00000E09A1020E979D@comcast.net>


There really is no 'best practice'. It depends on the quality of your developers and your organization. Question them to find out what they know about databases. If you are more comfortable with them, then give them more access. If you are less comfortable give them less. However, if you give less privileges you need to be more available to trouble shoot production issues to support them which means you may end up working longer hours and need to be available nights and weekends.

You could also train them. Its really not that hard to monitor what they are doing. If they go to far, have an email sent to you, kill their session and lock the account.

When I do production support I typically have query access to anything I need and typically a small schema if I need to copy data over. In another case, I had the Oracle password because the offical 'DBAs' did not have time to support us. Now I typically know when peak times are and only hit production hard during off-peak times(unless someone 3-4 levels above me in the chain of command says do it right now). The bottom line is you need people who have the skills necessary to do this work. So it's either you, the developers, or hire someone to do this. You can also work with them and train them to improve their knowledge.

The advantage to having members of the development run these queries is that they are closer to the code and understand the application better. So it's easier for them to troubleshoot issues. The big question is, do they know enough to do it?

The more hurdles that get put in the way, the less productive the team is and the costs to maintaining the application go up.

I frequently run into situations where production support folks (basically former developers converted to support their code now in production) would like to find more information out about what's going on within the database, yet don't have access to do so. For example, one weekly process performs a rather large DELETE. Ideally they'd have access to V$TRANSACTION and V$SESSION to get basic transaction information to track progress when it seems to be running long, but I'm reluctant to start granting access to V$ views on a production database.  

Another option is to create a wrapper procedure that runs a hardcoded query against V$ views, running as privileged user. But before I go this route I thought I'd check with you all on what you've done, on what would be the "best practice" for something like this. This kind of additional access for others is new for me because normally its completely locked down. But, my current client has a rather complex setup and it'd actually help me a bit if others could perform monitoring without me having to be the bottleneck.  

Thanks in advance for any feedback/examples.  

BTW, this is for Tru64 5.1 and RHEL4 running Oracle9.2.0.6 and 10.2.0.2.  

Dave



Dave Herring, DBA
Acxiom Corporation
3333 Finley
Downers Grove, IL 60515
wk: 630.944.4762
<mailto:dherri_at_acxiom.com>
 

"When I come home from work and see those little noses pressed against the windowpane, then I know I am a success" - Paul Faulkner  



The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged.

If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.

If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system.

Thank you.



--

http://www.freelists.org/webpage/oracle-l Received on Mon Sep 04 2006 - 12:22:20 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US