| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Oracle 911 Article
If Don wants to call me one of the 'theoreticians and ivory-tower
academics' I will call him a lesbian from now on. Maybe even a lesbian
red-neck. Yeah.
To quote Dave Ensor on something completely different: "What a daft Mickey Mouse-idea".
Mogens
Daniel W. Fink wrote:
> One of the problems with the article is that there is no proof (admitted by Don)
> as to why these decisions were made. I foresee problems when someone responds to
> a problem with "I read this in an article, so it will work." without
> understanding the throughts and reasoning behind the decision. I know that I did
> that as I was learning to be a DBA. Now, I can become frustratingly slow to the
> users as I work on the right solution. I also know the negative impact of
> "Change this and see what happens". I recall changing spin_count (on the advice
> of an Oracle Instructor) on a production system and listening to my pager
> beep...and beep...and beep...and beep. But, hey, I was following the advice of
> an expert!
>
> Offering solutions without explaining the reasoning is not responsible. Imagine
> going to the doctor with a pain in your side and then waking up in a hospital
> with a large scar on your stomach. No explanation, no discussion. The doctor
> knew what the problem was, took care of it and left without explanation. A year
> later, you have a pain in your head, so you tell a new doctor to perform an
> operation on your head (Sounds like a Monty Python episode). I've seen system
> performance crippled when someone notices missing stats and runs dbms_stats (or
> analyze). I've also seen performance crippled when statistics are removed. So
> what is my solution when performance goes down? Run parallel jobs, one analyzing
> the schemas and one deleting statistics.
>
> This does not mean that we have to perform 10046 traces, statspack reports for
> each and every performance problem. We don't need to set up test databases, run
> all permutations of every parameter, configuration, etc. For example, I was able
> to identify an update that was performing a full table scan (which are not
> always bad) on each update. After talking with the developer, we determined that
> the predicate was on a unique column, but did not have a unique constraint or
> even an index. I found the time spent with the developer to understand why the
> index would probably improve performance in this case (or similar cases) will
> help him properly design databases and develop applications. This prevents
> problems...the ounce of prevention.
>
> At the same time Don is indicting the 'theoreticians and ivory-tower academics',
> he is demonstrating the benefit of a scientific approach. Either that or Don is
> just plain lucky (not something I'd bank on nor do I think Don would describe
> his knowledge as such). Over time, Don has seen the impact of small
> sort_area_sizes and has learned to recognize the symptoms, so he is able to
> resolve these problems. I can't believe that Don would walk into a client and
> say "Change this, this and this" without performing some sort of examination and
> observation (which is the essence of a scientific approach).
>
> I disagree with any 'Silver Bullet' approach for several reasons. First, it
> encourages changes without understanding the real problem. Second, it can make
> real solutions slow (i.e. bumping freelists until buffer busy waits go away v.
> identifying what a valid value would be for the first change). Thirdly, for the
> less than skilled (including most management/users where Oracle skill is not a
> requirement) it sets unrealistic expectations.
>
> Finally, as I am a resident of Colorado, home of Coors Beer, the 'Silver Bullet'
> is Coors Light, which is one of the most foul contaminations of water that
> currently exists.
>
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sun Mar 07 2004 - 19:18:16 CST
 |
 |