Actually, I did know about the BHR thing, primarily from this list, just as you did. It was the indexing one that cought me off-guard. I was just using the former as a reference.
Speaking of which, your Don Quixote reference is priceless! "Facts are the enemy of truth." :D Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech International, Sussex, WI USA > -----Original Message----- > From: DENNIS WILLIAMS [mailto:DWILLIAMS@;LIFETOUCH.COM] > Sent: Monday, November 11, 2002 2:04 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Is nothing sacred? (Oracle vs The Experts) > > > Rich - Actually, if you took an Oracle Performance Tuning > class from Oracle > Education right now, you would find the BHR mentioned little > and Oracle > waits emphasized a great deal. I took that class about a > month ago and the > instructor described how Cary had prevailed in convincing the > people at > Oracle that counted and the class materials were being > rewritten for the > next class after mine. > Well, being a computer professional is a hard burden, what with the > underlying assumption ever changing. Actually, given the extensive > discussions we've had on this forum about BHR vs. waits, I'm > surprised it > caught you unawares. This was where I'd first heard about the > new emphasis > on waits. Of course, with waits becoming the conventional > wisdom, Cary and > others will have to find another windmill to tilt at. Cary - > anything lined > up? > Dennis Williams > DBA, 40%OCP > Lifetouch, Inc. > [EMAIL PROTECTED] > > > -----Original Message----- > Sent: Monday, November 11, 2002 10:58 AM > To: Multiple recipients of list ORACLE-L > > > So, there I am, on 8.1.7.2 (and .4) on HP/UX 11.0, with a > process that runs > 20 minutes out of every hour of the day (despite my protests to it's > design). After it starts having problems (go figure), it > becomes a priority > to speed it up. > > Thanks to a 10046 trace, we see that the query taking the > most elapsed time > does FTSs on each of two very small tables (1 block and 4 blocks -- 8K > blocksize). These tables are not indexed, as per the official Oracle > recommendation. After reading the excellent Hotsos paper > "When to index a > table" (THANKS, CARY!), I added an index to reduce elapsed > time on this > query by 50% (150 to 75 seconds in test), proving to me that > the paper is > valid. And I've only read to page four! > > OK, first I'm taught by Oracle to look at Buffer Cache Hit Ratios as a > measure of performance, then told (and thoroughly convinced) > by experts that > this is bunk. Now, I found out that the 15% (or 10% or > whatever, depending > on version) ratio of rows returned to total rows in > determining when to use > an index in a query is garbage. > > 1) Why is this? > > 2) What other pearls of performance wisdom from Oracle Corp should I > completely disregard as false? > > I know there's an Oracle Fallacy website somewhere... > > It just looks bad on me, our department, and Oracle when, once again, > something I've been preaching to our developers as gospel > turns out to be > completely false. > > Maybe I'm grumpy because it's snowing on my leaves right > now... <sigh> > > > Rich -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Jesse, Rich INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
