Re: why administrator refuse to give permission on PLUSTRACE

On Oct 29, 8:46 am, DA Morgan <damor..._at_psoug.org> wrote:
> Hasta wrote:
> > In article <1193490896.740..._at_bubbleator.drizzle.com>,
> > damor..._at_psoug.org says...
> >> there is nothing a developer can learn on a production
> >> server they can't learn from reading Cary Millsap's book, Jonathan
> >> Lewis' book, and looking at the metrics created by the DBA.
>
> >> A developer rummaging around a production instance trying to diagnose
> >> what the DBA can not? If you can provide a scenario where this looks
> >> like a good idea I'd be interested in considering it.
>
> > Daniel,
>
> > to write *really* good, efficient programs, a programmer
> > must see its code executing in production. S/he needs
> > to get the feeling, the "haha" experience that only
> > confrontation with reality can provide.
>
> > Figures and methods are not enough. They are too
> > abstract. Whenever a programmer is disconnected from
> > reality, most often he'll write sub-optimal programs.
>
> > Note that a development system a never a full
> > simulation of a production system.
>
> > Regards
>
> No you don't. Seriously ... you don't. Provided, as I said in my post
> that your test environment isn't just a joke.

There is a lot of humor in the world, much not very funny. But the haha aha was pretty good! :-)

>
> To look at how your code is running in production what do you propose
> to do? Run 10046 traces? 10053 traces? Get SELECT on every dba_ and gv$
> view? Run ad hoc SQL? Assuming you are competent enough to know what to
> look at and for what are you going to learn there that the DBA couldn't
> give you by running StatsPack every 20 minutes?
>
> Sorry ... I'm not buying what you're selling ... unless you can flesh it
> out with specifics about what you can do that your DBA can not.

The difference is functional application knowledge. It's simply too much to ask in most environments that there be perfect flow of requirements from users to programmers and then through implementation DBA's back to users. Yes, these things should be caught in acceptance testing and before, but the reality is lots gets shoved into production as soon as it appears ready. In the rapid development milieu this gets amplified. It's not necessarily a bad thing. It can be disastrous. Most of the time short circuiting the proper way of doing things works well enough, since doing it proper is way too expensive and wouldn't get done at all.

I've seen some developers I would not want poking at a production db with an 11 foot pole do OK, in spite of themselves. I've seen excellent DBA's make mistakes. Proper procedures are a good thing to aim for, but often too much to expect.

jg

--
@home.com is bogus.
http://consumerist.com/consumer/fraud/best-buy-sells-you-a-box-of-bathroom-tiles-instead-of-hard-drive-wont-refund-315873.php