Re: why administrator refuse to give permission on PLUSTRACE

From: DA Morgan <damorgan_at_psoug.org>
Date: Wed, 07 Nov 2007 13:34:41 -0800
Message-ID: <1194471276.509212@bubbleator.drizzle.com>

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

>> Hasta wrote:
>>> In article <1194368023.130238_at_bubbleator.drizzle.com>, 
>>> damorgan_at_psoug.org says...
>>>>> 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.
>>> No, the dba is not incompetent.  Read on.
>>>
>>>>> 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.
>>>>
>>> OK. Developper gets a bug report that the system is slow with
>>> 5,000 docs per person.
>>>
>>> But developper is aware that the system is designed - by 
>>> specification - to work smoothly for 500 documents per 
>>> person - it is not designed to work with 5,000 (or 5,000,000)
>>> such documents.
>> Wrong! Wrong! Wrong!
>>
>> DBA is incompetent or untrained because there is nothing about
>> that subject the developers should know that the DBA does not
>> know. If the DBA doesn't know it then somebody had best be
>> pointing fingers and fixing problems.
>>
>> What you are describing as your work environment is a change
>> management nightmare.

>
> My work environment is a third party software provider.
> The dba is a customer employee.
>
> Your claim is that the customer dba should be aware of
> all internal specifications of a third package ?
>
> Expected maximum response time of all queries ?
> Maximum size of all tables - including esoteric ones ?
> Rough execution time of all stored procedures ?

Yes. If not the DBA is basically occupying space and wasting otherwise valuable oxygen.

Esoteric ones? No table that can change its size is esoteric.

>> I will ask the question one more time.
>> What is your testing methodology for identifying production problems?
>> What is it you are doing in production that the DBA can not do?

>
> I'm not escaping the Daniel.
>
> Actually, I am answering it right now, with an example from
> real-life. Of course I already know the root cause of the
> problem and the correct soluion to the problem.

No you aren't. You didn't answer anything. You ran and hid in the closet yet again.

-- 
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 Wed Nov 07 2007 - 15:34:41 CST