Re: why administrator refuse to give permission on PLUSTRACE

On Nov 7, 1:34 pm, DA Morgan <damor..._at_psoug.org> wrote:
> Hasta wrote:
> > In article <1194373836.984..._at_bubbleator.drizzle.com>,
> > damor..._at_psoug.org says...
> >> Hasta wrote:
> >>> In article <1194368023.130..._at_bubbleator.drizzle.com>,
> >>> damor..._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.

Having spent several years providing DBA support as Hasta is describing, and many more on the other side of the fence, I must say, he's totally right on this one IME. In fact, I've seen otherwise competent DBA's throw up their hands when confronted with some of the weird stuff a large aerospace app (for just one example) tosses at them, where I've been able to deal with it simply because my expectations aren't what you advocate. When there are thousands of tables and you can't know what they all do, much depends on flags, esoteric doesn't begin to describe it - but inflexibility will lead to failure. Now in that particular case, I was the (primary) DBA, and there were dozens of developers modifying old and implementing new code, and I was passionate about not letting them mess with the production system - but there were still times when management insisted (and in retrospect, correctly - not to mention "insisted" is an understatement when a .mil is involved!) on letting certain things happen - I dealt with that by simply insisting that a DBA be involved, to know what was going on. In the end, the critical issue was not whether a developer could poke stuff into production with TOAD (horrors!), but whether the action could be tracked and any effects be accounted for, particularly if it fixed the problem. While I agree "the DBA" should know "the app," above a certain scale there is simply too much for one person to deal with. The issue has grown with the more modern technology stacks. There were some nightmares, but change management wasn't the worst.

>
> 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.

jg

--
@home.com is bogus.
More zombies for the spambots!  http://www.news.com/8301-10784_3-9812297-7.html