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 <[EMAIL PROTECTED]> > Date: 2003/10/06 Mon AM 09:34:25 EDT > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > 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. > [EMAIL PROTECTED] > > > -----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----- > [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> > > Date: 2003/10/02 Thu PM 12:34:33 EDT > > To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> > > 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: [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.net > -- > Author: <[EMAIL PROTECTED] > 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.net > -- > Author: Cary Millsap > 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.net > -- > 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). > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: <[EMAIL PROTECTED] 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).
