Re: why administrator refuse to give permission on PLUSTRACE

On Nov 2, 12:35 pm, DA Morgan <damor..._at_psoug.org> wrote:
> Marc Blum wrote:
> > On Fri, 26 Oct 2007 23:11:51 -0700, DA Morgan <damor..._at_psoug.org> wrote:
>
> >> 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.
>
> > Maybe because there's some urgent issue to be solved, maybe production ist
> > coming to a grinding halt and there's a need for someone who knows the
> > requirements and the implementation and the technology to get rid of the issue
> > NOW! Production DBAs fail in the first and second point.
>
> Great generalities. But lets pursue this. You are that developer. What
> privileges do you require? What are you going to do? Lets see specifics.
> I am really interested in hearing from any developer that thinks they
> can justify this.
>
> From my perspective ... the applicatoin came to a grinding halt. What is
> step #1? In my book it is determine what came to a halt. Was it the
> application running on a client? The developer use useless. Was it a
> network router or hub? The developer is useless. Was it a storage
> related issue? The developer is useless. Did the server crash at the
> operating system or instance level? The developer is useless. Anyone
> that is a developer want to demonstrate their skill in addressing this
> specific issue "production ist coming to a grinding halt" and tell me
> what they would do. Thanks.

OK, I got halfway through writing a response to your reply to me and ran out of time, sometime hopefully I'll finish that :-)

Anyways, your post here was the sort of problem that got me my current major client. They did not call me in as a DBA, at the time they didn't know what a DBA was (and still don't entirely believe me :-) . They called me in as someone skilled in the obscure technology stack they had, who just happened to also know unix and Oracle. It was a developer problem, and I fixed it as a developer. As it happened, I didn't have to do jack to figure it out - it was a simple issue of the bad developer having forgotten the documented limits of a feature, I saw it as soon as I looked at the code, even though I hadn't seen such code in several years. So I wrote code that bypassed both that problem and the inherent Oracle limitations (at that time on that configuration - the solution would be different now, because Oracle and the hardware are better - but why change it? Plenty of more pressing issues.). There were other people who were and are better than me at coding that stuff - but they weren't around that particular customer, and those who were there didn't get that job done (and I'm still finding landmines in their code years later, not to mention in the vendor's code).

Perhaps more relevant, I've seen this plenty of other times. Remember, most performance problems do come from the code, so even as a scattershot, having a developer knowledgeable about the circumstances can work, and as someone else pointed out, may enlarge their knowledge space by seeing what people are actually doing. It is certainly not the best way to do things, but as Galen points out, normal. Vulgar, even. In small shops, people wear many hats. In large shops, management feel lucky to get someone from the vendor to muck about in their production system and laugh patronizingly at the horrified looks on the DBA faces.

jg

--
@home.com is bogus.
http://yro.slashdot.org/yro/01/03/16/1256226.shtml