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

thanks guys. Im only familiar with the oracle database, so I dont know if I can believe what I read when dealing with other databases.

so I wanted to check. while we are on the topic of other databases. What kind of wait interface's do other databases provide? How robust are they?
>
> From: DENNIS WILLIAMS <DWILLIAMS_at_LIFETOUCH.COM>
> Date: 2003/10/06 Mon AM 09:34:25 EDT
> To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> Subject: RE: Re: Physical I/O and databases other than oracle
>
> 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).
>

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