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