Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Re: Physical I/O and databases other than oracle

RE: Re: Physical I/O and databases other than oracle

From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
Date: Mon, 06 Oct 2003 05:34:25 -0800
Message-ID: <F001.005D22B7.20031006053425@fatcity.com>


Cary - Thanks so much for providing the historical perspective on this issue. Perhaps you could confirm or refute a theory of mine. My theory is that in the early days of databases, most of the guidelines for database tuning came from benchmarks. This was an activity that received a lot of top-notch resources, and produced objective, numerical results. But in some cases what worked well for a benchmark with just a few programs might be misleading for an operating production system. Can you confirm or refute this idea?

   And thanks for setting your methods down in your book.

Dennis Williams
DBA, 80%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com

-----Original Message-----
Sent: Sunday, October 05, 2003 3:14 PM
To: Multiple recipients of list ORACLE-L

I would expect that any vendor with a product whose bottleneck is the same for all implementations would have been long dead by now. The answer is probably that any product's "the bottleneck" will vary hugely from one configuration and implementation to the next.

It has always been this way with Oracle as well (where "always" is defined as "at least since I joined Oracle in 1989"). The idea that "the bottleneck" in Oracle was ever "always physical I/O" is *very* false. It's just that many of the popular measurement tools we used back in the 1980s and 90s were capable only of revealing I/O bottlenecks. But a very common Oracle bottleneck in 1990 was CPU consumed by excessive LIO processing and excessive parsing. This is not a new truth, just a new awareness.

By the way, the BCHR was never any more useful than it is today. It was, of course, a much larger component of the "tuner's portfolio" than today. Actually, don't misunderstand: the BCHR *is* useful, and it always has been. When it's really close to 100%, it's an almost total guarantee that you have some really serious performance problems. This statement has been true since at least Oracle V5...

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:

- Performance Diagnosis 101: 10/28 Phoenix, 11/19 Sydney
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit www.hotsos.com for schedule details...


-----Original Message-----
rgaffuri_at_cox.net
Sent: Thursday, October 02, 2003 12:15 PM To: Multiple recipients of list ORACLE-L

my email states that in oracle this isnt true. HOWEVER, what about other databases?
>
> From: Mladen Gogala <mladen_at_wangtrading.com>
> Date: 2003/10/02 Thu PM 12:34:33 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: Re: Physical I/O and databases other than oracle
>
> On Thu, 2003-10-02 at 11:44, Garry Gillies wrote:
> > > Im reading an academic book on databases and it states that
Physical I/O
>
> > Eh?
> > What IS the primary bottleneck in tuning Oracle?
>
> Cache hit ratio. You tune the buffer cache hit ratio (BCHR) and your
job
> is done. Database with 99.9% BCHR must be OK.
>
>
>
>
> Note:
> This message is for the named person's use only. It may contain
confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Wang Trading LLC and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks.
> Any views expressed in this message are those of the individual
sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Mladen Gogala
> INET: mladen_at_wangtrading.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_at_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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: <rgaffuri_at_cox.net
  INET: rgaffuri_at_cox.net

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

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Cary Millsap
  INET: cary.millsap_at_hotsos.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_at_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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: DENNIS WILLIAMS
  INET: DWILLIAMS_at_LIFETOUCH.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_at_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).
Received on Mon Oct 06 2003 - 08:34:25 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US