!READ THIS Important Message!
- From: Jared.Still@xxxxxxxxxxx
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 8 Mar 2004 09:29:02 -0800
This is a forum for Oracle technical issues and other related issues.
The language used in the post below is wholly inappropriate.
This is not a forum for name calling, criticism of articles, or personal
debates.
If you want to provide constructive criticism of articles or have personal
discussions
on topics not related to Oracle, feel free to do it somewhere else.
Constructive criticism has its place, but it is clear that this has gone
far
beyond that. If you feel need for rebuttal, write it in dbazine.com, or
wherever
the target of your criticism resides.
This forum is provided as a technical service to the Oracle community.
Freelists.org is kind enough to provide the means for this free of charge.
I personally do not need the headaches and stress of dealing with this.
If off-topic posts continue I will start blocking addresses.
That is merely a stop gap measure that is due diligence on my part.
If the off topic stuff continues after that, I will shut down the list,
pure and simple.
Someone else is free to take on the responsibility. At this moment, I am
strongly inclined to just shut it down.
Jared
Mogens Nørgaard <mln@xxxxxxxxxxxx>
Sent by: oracle-l-bounce@xxxxxxxxxxxxx
03/07/2004 05:20 PM
Please respond to oracle-l
To: oracle-l@xxxxxxxxxxxxx
cc:
Subject: 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.
>
Other related posts:
