Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Usenet -> c.d.o.server -> Re: why administrator refuse to give permission on PLUSTRACE

Re: why administrator refuse to give permission on PLUSTRACE

From: Robert Klemme <>
Date: Sun, 28 Oct 2007 14:25:30 +0100
Message-ID: <>

On 27.10.2007 15:15, DA Morgan wrote:

> Robert Klemme wrote:

>> On 27.10.2007 08:11, DA Morgan wrote:
>>> Mark D Powell wrote:
>>>> I do not consider autotrace as being a necessity.
>>> I do.
>>>> Regular explain plan is usually good enough.
>>> The emphasis being, in my oopinion on "usually."
>>>> I suspect the DBA does not want
>>>> developers running poorly performing SQL on production in order to get
>>>> an autotrace to tune the SQL with when the developer should have just
>>>> ran explain plan first.
>>> Here I agree and I will go one step further. No developer should ever
>>> have access to a production database except as an end-user utilizing the
>>> application. I've yet to see a legitimate reason for any developer to
>>> have production access privs.
>> I'm not sure I agree here - at least not with that level of
>> strictness. There may be situations where a collaborative team effort
>> (engineering and DBA) is needed to hunt down an issue that occurs on a
>> production system. Sometimes it's not possible to recreate the same
>> situation on a development / test system (because of load, data or
>> time) and looking into the production system is the only chance.
>> Granted, access could be given temporarily or all parties could sit
>> together in front of the DBA's terminal.
>> And then there are of course those shops too small to have their own
>> DBA and that need to rely on the software provider to determine the
>> root cause of an issue. I know, this should not happen (i.e. an
>> Oracle without a DBA) but in practice...
> Assuming a competent DBA, one that knows how to run traces, one that

 From my experience, that's a requirement which is not met at all sites...

> knows how to create a StatsPack or run AWR, or one that can run queries
> against ASH ... there is nothing a developer can learn on a production
> server they can't learn from reading Cary Millsap's book, Jonathan
> Lewis' book, and looking at the metrics created by the DBA.

Completely agree.

> A developer rummaging around a production instance trying to diagnose
> what the DBA can not? If you can provide a scenario where this looks
> like a good idea I'd be interested in considering it.

I did not meant to mandate this as the standard approach. I just think that your rule does not fit all situations in reality. If you take it as guideline I am completely fine with it.

Having said that, there may be situations where communication between DBA and development is difficult and / or (too) slow (time zones and languages come to mind) where it is better / faster to have development pull the data they need. Of course, developers then need to be competent DBA's as well...


        robert Received on Sun Oct 28 2007 - 08:25:30 CDT

Original text of this message