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