Return-Path: <root@fatcity.cts.com>
Received: from ensim.rackshack.net (root@localhost)
 by orafaq.net (8.11.6/8.11.6) with ESMTP id gABN8xg07993
 for <oracle-l@orafaq.net>; Mon, 11 Nov 2002 17:08:59 -0600
X-ClientAddr: 209.68.248.164
Received: from newsfeed.cts.com (newsfeed.cts.com [209.68.248.164])
 by ensim.rackshack.net (8.11.6/8.11.6) with ESMTP id gABN8wX07987
 for <oracle-l@orafaq.net>; Mon, 11 Nov 2002 17:08:58 -0600
Received: from fatcity.UUCP (uucp@localhost)
 by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id MAA72292;
 Mon, 11 Nov 2002 12:49:49 -0800 (PST)
Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 00500539; Mon, 11 Nov 2002 12:43:35 -0800
Message-ID: <F001.00500539.20021111124335@fatcity.com>
Date: Mon, 11 Nov 2002 12:43:35 -0800
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
X-Comment: Oracle RDBMS Community Forum
X-Sender: "Jesse, Rich" <Rich.Jesse@qtiworld.com>
Sender: root@fatcity.com
Reply-To: ORACLE-L@fatcity.com
Errors-To: ML-ERRORS@fatcity.com
From: "Jesse, Rich" <Rich.Jesse@qtiworld.com>
Subject: RE: Is nothing sacred? (Oracle vs The Experts)
Organization: Fat City Network Services, San Diego, California
X-ListServer: v1.0g, build 72; ListGuru (c) 1996-2001 Bruce A. Bergman
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain;	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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
Rich.Jesse@qtiworld.com              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.
> dwilliams@lifetouch.com 
> 
> 
> -----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: Rich.Jesse@qtiworld.com

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: ListGuru@fatcity.com (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).

