Re: DBA Skill tree

This is why I started that section with explain plan and ALL the functions by which Oracle accesses blocks - if the SQL is wrong to begin with a junior DBA should be able to recognize this. If the SQL is inefficient in the manner in which blocks are accessed, it should be rewritten.

Also, it's another reason this section is named "Tuning SQL" - not tuning code. Earlier in my post, I included a foundation of knowledge (thanks Mark) which includes [at least] a couple of years developing SQL & PL/SQL as well as programing in a lower level language - I believe a DBA should be able to recognize bad programming, structure, flow, etc. IMHO, a DBA should be able to assist and train developers on not only access to the database, but also higher level areas like algorithms, the influences of different methods of compilation and/or interpretation, i.e. a compiler construction course should be considered foundational.
[dragon book anyone :)]

On Tue, Apr 7, 2009 at 1:07 AM, Stephane Faroult <sfaroult_at_roughsea.com>wrote:

> Rich,
>
> I've been following this thread with interest, but I became utterly
> uncomfortable when I saw this
> > Tuning SQL - starting with explain plan and ALL the functions by which
> > Oracle accesses blocks, moving through the optimizer and finally newer
> > features like AWR, SQL tuning sets, profiling, etc. Add to this the
> > different methods by which the execution plan can be influenced -
> > stats, hints, profiles/outlines, etc.
> First, let me state upfront that I acknowledge that you haven't always
> access to the code and that dirty tricks are sometimes the only option
> where "real politik" is concerned.
>
> Nevertheless, I can't agree with all this. Understanding, at least in
> the broad lines, how the optimizer works, and more particularly what it
> needs for performing well and what can lead it astray, yes, definitely.
> Profiling to know where time is spent, I couldn't agree more. But I've
> seen too many people trying to fix execution plans when the SQL code was
> obviously flawed in the first place, not to mention these functions that
> open a cursor, loop, and increase in the loop the counter they return in
> the end (true story; still in production. I found the code, a friend of
> mine forwarded it to Tom Kyte who mentioned it on his blog some time ago).
>
> I guess we all know on this list that when something is wrong, the
> database is blamed, and by extension the DBA. If you consider that your
> job consists in silently fixing any stupid mistake, you're just turning
> the other cheek, which may have high moral value but is just plain wrong
> in this context; don't get me started on the optimizer starting to
> out-smart developers and rewrite everything in their back. I strongly
> believe that the same is true of code as of start-ups: better to fail
> fast than to painfully hobble (comparison with the economy also
> springing to mind). Influencing the execution plan is a moral hazard.
> Detecting what is wrong, explaining what is wrong and why it is wrong,
> advising what to do instead, yes. Even for 3rd party software. You won't
> fight entropy by tweaking parameters that nobody understands but you.
>
> --
> Stephane Faroult
> RoughSea Ltd <http://www.roughsea.com>
>
>

--
http://www.freelists.org/webpage/oracle-l