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...
Cheers
robert
Received on Sun Oct 28 2007 - 08:25:30 CDT