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


Rich Jesse                           System/Database Administrator
[EMAIL PROTECTED]              Quad/Tech International, Sussex, WI USA

Disclaimer:  I only said the Packers would be 12-4 this year -- I never said
that they couldn't do better!  WOO-HOO!  :)
-- 
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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: DENNIS WILLIAMS
  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).

Reply via email to