Re: why administrator refuse to give permission on PLUSTRACE

From: DA Morgan <damorgan_at_psoug.org>
Date: Tue, 06 Nov 2007 10:30:40 -0800
Message-ID: <1194373836.984381@bubbleator.drizzle.com>

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.

> What's happening, now ?

Chaos.

>> Should I presume your answer would be that you throw untested code
>> into prod 

>
> Nope. The system has been carefully designed, developped and
> load tested according to specifications : response time of
> less than one sec, given at most 500 docs per person.

Nonsense. You just told me you were working on production doing things the DBA couldn't do. Now you want to backtrack to a nice clean dev and test environment.

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?

Bet you don't answer a second time. <g>

-- 
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 - 12:30:40 CST