Re: why administrator refuse to give permission on PLUSTRACE

From: DA Morgan <damorgan_at_psoug.org>
Date: Tue, 06 Nov 2007 08:53:46 -0800
Message-ID: <1194368023.130238@bubbleator.drizzle.com>

Hasta wrote:
> In article <1194284665.769857_at_bubbleator.drizzle.com>,
> damorgan_at_psoug.org says...

>> Hasta wrote:
>>> In article <1194206398.972648_at_bubbleator.drizzle.com>, 
>>> damorgan_at_psoug.org says...
>>>> My point was that while the developers here seemed more than willing to
>>>> point fingers at incompetent DBAs from my experience the developers are
>>>> equally guilty of not keeping their skills current. Not more so ...
>>>> equally so.
>>> Well, honnestly, I haven't seen a lot of developpers 
>>> in this group claiming that dbas are generally incompetent.
>>>
>>> I have seen them claiming that a dba is unlikely 
>>> to find the root cause of an application problem 
>>> alone, for reasons that are very understandable 
>>> and unrelated to his/her competency.
>> You are dissembling. Identifying root causes on a production server is
>> a core competency of the DBA job in the vast majority of organizations.

>
>
> A good dba can certainly find one cause in the causal chain.
>
> However, he does not know the specifications of the components
> of the system. Without a specification, he cannot identify
> with certaincy the root component that is misbehaving.

Then he or she is incompetent and should be trained or replaced.

> I'll try again, for the last time. Please read and answer :
>
> Let's assume your own (doc_id, person_id, doc_name) table
> with an index on person_id.
>
> The dba finds that a query by person_id is too
> slow when processing five thousand rows.
>
> Now, what does he do ?

Reports that back to the developer who fixes it in the dev environment and validates the fix in test.

Should I presume your answer would be that you throw untested code into prod while holding a lucky rabbit's foot in your left hand.

>> if you are trying to say that developers are trained in the use of
>> StatsPack but DBAs are not I'd like to see that explicitly stated.

>
> I certainly dont state that

Good because we both know it isn't true. It should be, perhaps, but it isn't the case. And without StatsPack you are going to find the bad SQL by what methodology? Crystal ball? Tarot cards? Ouija Board?

>> If you think that developers, who by tradition are not allowed to see
>> dba_ and v$ and gv$ views are trained to use them I would like to see
>> that stated too

>
> Yes, we inspect dba et v$ views in production.

Which means you have been granted what privileges by the DBA?

>> I think you have demonstrated substantial creativity >> not matched by reality.

Actually I have a substantially level of creativity matched by having read "best practice" docs at some of the most highly successful Oracle shops on the planet and working in a few myself.

> And conversely, I think you look disconnected from reality ;-)
> (No offence meant, Daniel, really)

No offense taken. But I will be very interested in seeing your methodology, when in production, for finding and fixing problem statements.

My guess is your databases are sized in MB or GB ... not TB.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

Received on Tue Nov 06 2007 - 10:53:46 CST