Re: Oracle 911 Article
- From: "Daniel W. Fink" <Daniel.Fink@xxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 05 Mar 2004 08:46:59 -0700
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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
