Re: V$ access for production support
- From: ryan_gaffuri@xxxxxxxxxxx
- To: Dave.Herring@xxxxxxxxxx, "oracle-l" <oracle-l@xxxxxxxxxxxxx>
- Date: Mon, 04 Sep 2006 17:22:20 +0000
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.
-------------- Original message --------------
From: "Herring Dave - dherri" <Dave.Herring@xxxxxxxxxx>
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@xxxxxxxxxx>
-------------------------------------
"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.
*************************************************************************
Other related posts:
