Return-Path: Received: from ensim.rackshack.net (root@localhost) by orafaq.net (8.11.6/8.11.6) with ESMTP id h0TBqTv21256 for ; Wed, 29 Jan 2003 05:52:29 -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 h0TBoam21097 for ; Wed, 29 Jan 2003 05:51:12 -0600 Received: from fatcity.UUCP (uucp@localhost) by newsfeed.cts.com (8.9.3/8.9.3) with UUCP id AAA43999; Wed, 29 Jan 2003 00:33:34 -0800 (PST) Received: by fatcity.com (26-Feb-2001/v1.0g-b72/bab) via UUCP id 0053CE39; Tue, 28 Jan 2003 23:53:40 -0800 Message-ID: Date: Tue, 28 Jan 2003 23:53:40 -0800 To: Multiple recipients of list ORACLE-L X-Comment: Oracle RDBMS Community Forum X-Sender: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= Sender: root@fatcity.com Reply-To: ORACLE-L@fatcity.com Errors-To: ML-ERRORS@fatcity.com From: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= Subject: Re: BCHR Tuning 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: multipart/alternative; boundary="------------080006000809020802030100" --------------080006000809020802030100 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ferenc, If I didn't say it before, I'll say it now: This was one of the better messages I've seen for a very long time. Jolly good laugh, as the English would say. Remind me to take you to lunch next time I'm in Melbourne (as if I'm in Australia very often ... ). Take care. Mogens mantfield wrote: >Morgens is very correct in saying tha all sorts of measurements have their >place. Actually, the length-of-skirt measurement works very well for me. >Here is the algorithm: > >Heat-by-day in inversely proportional to length of skirt which again is >inversely proportional to my desire to have lunch outdoors at sidewalk >cafe, but which directly affects my enjoyment of the day and inversely >affects my productivity (much like this posting). > >Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by >day, 20 by night = absolute bliss), so I get a lot of opportunity to >streamline the algorithm and processes. Melbourne is the place to be, >unless you can get to work on Bondi beach in Sydney, where the skirt length >= zero. > >Of course, if you study the skirts or lack of it TOO intensely, this leads >a high jealous-boyfriend-hit-ratio, which inversely affects my overall >well-being and morale, so you need to find that optimal balance between >appreciation and blatant gawking or technically put : maximum benefit >within minimized response time. > >Ferenc Mantfeld > >-----Original Message----- >From: Mogens Norgaard [SMTP:mln@miracleas.dk] >Sent: Tuesday, January 14, 2003 12:00 PM >To: Multiple recipients of list ORACLE-L >Subject: Re: BCHR Tuning > >Something here doesn't compute. If you tried to use time-based >measurements and didn't find out where the time went - well, bad for >you. If you then stumbled on something, say the database >startup/database shutdown ratio (would normally be fairly close to 1, >but could vary) or the log file switch/archive log file ratio (again, >could be close to 1 or 100% or something - or could vary) or the ratio >of blocks from a certain index found in the permanent pool versus the >number of PIO's required for that statement - or whatever - it would >still be guesswork, checklist tuning, or what you'd prefer to call it. > >All sorts of measures have their place. All sorts of measures could >prove interesting. When I went to school the famous example was the wolf >population of Canada which seemed to follow the birthrate of children in >Denmark. Or the length of skirts versus economic prosperity in the >Western world, which also proved rather closely matched. > >If you want to measure response time (what else?) it just might be of >interest to find out where the time is spent. > >The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or >measurements might be important to find out symptoms of things - but to >say that that kind of guesswork still has it's place is like saying that >we should still carefully watch the wolf population of Canada or the >skirt length in the Western World...because you never know. > >And that just might be the case: You never (will) know until you adopt >an approach that is hierachical (spelling?) and which you can use to >prioritize and quantify your efforts (try that with the BCHR - the >x$kcbrbh, etc. of course are grossly wrong in those respects). > >Yep, I've been there, I've used it all, I've tried to use all the notes >and articles regarding the wonderful statistics available in bstat/estat >- I've been through the stages of collecting more and more queries and >numbers and ratios until my file with scripts and queries was bigger >than Holland. Yet it never gave me solutions, just a lot of things to >check and change and fiddle with - without knowing which one to choose >first, and how much it would help. > >The YAPP method works. There are cases where it is not 100% accurate. In >most cases it's spot on. Watch where the monitoring tools are going. >Spotlight in the latest edition have the YAPP method built in. Let's see >what Oracle does in 10i. Precise has it. Steve Adams' scripts has it. > >This is not about the BCHR being low or high or in between. This is >about using a METHOD instead of 100s of different numbers that don't >mean anything. > >Mogens > >Rajesh.Rao@jpmchase.com wrote: > > > >>I too think the BCHR has its place, as a problem indicator. It can tell me >>theres something wrong with my database. Say, I have this database >>performing well, the users are happy, the BHR is mostly at 90%, and now it >>suddenly shoots down to 70%, or it suddenly increases to 98. Somethings >>amiss. Its less tasking, to code for scripts that query v$sysstat to >>indicate me of some problems, rather than querying v$sqlarea. Or I need to >>code for some intelligent scripts to query v$session_wait or >>V$system_event. Or I need to look at the statspack reports every hour. The >>point is when do I look at wait events? When the user calls me up? >> >>All the papers out there, asking us rightly, to look at wait events, trash >>the BCHR. I think what the authors intended was to tell us that increasing >>DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of >> >> >99% > > >>does not mean a highly efficient database. Vice Versa, a BCHR of 50% does >>not indicate a poorly performing database. Give me a database with a 45% >>BHR, and I can get it to 99% by running a few queries. Point well >>understood. It does not mean in any way that I should now ignore PIO's and >>start tuning LIO's. >> >>I still use BCHR. "What you infer from the BCHR is what counts". >> >>Raj >> >> >> >> >> >> >> >> > > > >> "Yechiel >> >> > > > >> Adar" To: Multiple recipients of >> >> >list ORACLE-L > > >> > .net.il> Subject: Re: BCHR Tuning >> Sent by: >> >> > > > >> root@fatcity. >> >> > > > >> com >> >> > > > > > > > > > >> January 13, >> >> > > > >> 2003 10:58 AM >> >> > > > >> Please >> >> > > > >> respond to >> >> > > > >> ORACLE-L >> >> > > > > > > > > > >> >> >>Hello Anjo >> >>I just had a tuning session with Dov Hit, from ACS in Israel. >>He used some of the scripts that you showed him 2 years ago when you did >>some work for Amdocs. >>Anyway, after doing some search on the waits, he checked the BCHR and >> >> >found > > >>out that this database has only 40%. That led us on further checks and we >>found more offending SQL's. >> >>The BCHR has it's place. >>Just do not measure yourself JUST by it. >> >> >>Yechiel Adar >>Mehish >>----- Original Message ----- >>To: Multiple recipients of list ORACLE-L >>Sent: Monday, January 13, 2003 3:03 AM >> >> >> >> >> >> >>>Hmm, >>> >>>Lately? That actually started publicly in 1998 as far as I am concerned >>> >>> >>> >>> >>;-) >> >> >> >> >>>And acutally long before that. >>> >>>Anjo. >>> >>>----- Original Message ----- >>>To: "Multiple recipients of list ORACLE-L" >>>Sent: Sunday, January 12, 2003 11:43 PM >>> >>> >>> >>> >>> >>> >>>>On Friday 10 January 2003 14:48, Mogens Norgaard wrote: >>>> >>>> >>>> >>>> >>>>>Obviously, we don't know what we're talking about. I can see there's >>>>> >>>>> >>>>> >>>>> >>a >> >> >> >> >>>>>presentation by Rich Niemich at IOUG-A where he'll address all those >>>>>idiots who are saying you should ignore the Cash Hit Ratio (and who >>>>> >>>>> >>>>> >>>>> >>are >> >> >> >> >>>>>all just after making big money on their products - I loved that >>>>> >>>>> >>>>> >>>>> >>one). >> >> >> >> >>>>>>Or modify the set up of these tools to take action when BCHR >>>>>> >>>>>> >>>>>> >>>>>> >>>falls...... >>> >>> >>> >>> >>>>Here's the session info: >>>> >>>>Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM >>>>Venue: Southern Hemisphere 2, Walt Disney World >>>> Dolphin, Lake Buena Vista, FL >>>> >>>>Abstract: Lately, there has been a big push to ignore your >>>>hit ratio with claims that it is meaningless. This shallow >>>>minded view (usually by people who sell a tuning tool) ignores >>>>why people look at hit ratios and what they are looking for. >>>>This quick tip talk will show you what to look for and why. >>>>You will definitely know when, where & why to look at your >>>>hit ratio in the future. >>>> >>>>Show you why your hit ratio matters. How to analyze the >>>>hit ratio. Fallacies by those who want to sell you products >>>>and tools instead. >>>> >>>> >>>>Shallow Minded ?! >>>> >>>>Jared >>>>-- >>>> >>>> >>>> >>>> >> >> >> >> >> > > << File: ATT00021.htm >> > > --------------080006000809020802030100 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Ferenc,

If I didn't say it before, I'll say it now: This was one of the better messages I've seen for a very long time. Jolly good laugh, as the English would say.

Remind me to take you to lunch next time I'm in Melbourne (as if I'm in Australia very often ... ).

Take care.

Mogens

mantfield wrote:
Morgens is very correct in saying tha all sorts of measurements have their 
place. Actually, the length-of-skirt measurement works very well for me. 
Here is the algorithm:

Heat-by-day in inversely proportional to length of skirt which again is 
inversely proportional to my desire to have lunch outdoors at sidewalk 
cafe, but which directly affects my enjoyment of the day and inversely 
affects my productivity (much like this posting).

Right now (Jan / Feb), we are experiencing our heatwaves (30+ Celsius by 
day, 20 by night = absolute bliss), so I get a lot of opportunity to 
streamline the algorithm and processes. Melbourne is the place to be, 
unless you can get to work on Bondi beach in Sydney, where the skirt length 
= zero.

Of course, if you study the skirts or lack of it TOO intensely, this leads 
a high jealous-boyfriend-hit-ratio, which inversely affects my overall 
well-being and morale, so you need to find that optimal balance between 
appreciation and blatant gawking or technically put : maximum benefit 
within minimized response time.

Ferenc Mantfeld

-----Original Message-----
From:	Mogens Norgaard [SMTP:mln@miracleas.dk]
Sent:	Tuesday, January 14, 2003 12:00 PM
To:	Multiple recipients of list ORACLE-L
Subject:	Re: BCHR Tuning

Something here doesn't compute. If you tried to use time-based
measurements and didn't find out where the time went - well, bad for
you. If you then stumbled on something, say the database
startup/database shutdown ratio (would normally be fairly close to 1,
but could vary) or the log file switch/archive log file ratio (again,
could be close to 1 or 100% or something - or could vary) or the ratio
of blocks from a certain index found in the permanent pool versus the
number of PIO's required for that statement - or whatever - it would
still be guesswork, checklist tuning, or what you'd prefer to call it.

All sorts of measures have their place. All sorts of measures could
prove interesting. When I went to school the famous example was the wolf
population of Canada which seemed to follow the birthrate of children in
Denmark. Or the length of skirts versus economic prosperity in the
Western world, which also proved rather closely matched.

If you want to measure response time (what else?) it just might be of
interest to find out where the time is spent.

The BCHR, the x/y, the DBStarup/DBShutdown ratio or other ratios or
measurements might be important to find out symptoms of things - but to
say that that kind of guesswork still has it's place is like saying that
we should still carefully watch the wolf population of Canada or the
skirt length in the Western World...because you never know.

And that just might be the case: You never (will) know until you adopt
an approach that is hierachical (spelling?) and which you can use to
prioritize and quantify your efforts (try that with the BCHR - the
x$kcbrbh, etc. of course are grossly wrong in those respects).

Yep, I've been there, I've used it all, I've tried to use all the notes
and articles regarding the wonderful statistics available in bstat/estat
- I've been through the stages of collecting more and more queries and
numbers and ratios until my file with scripts and queries was bigger
than Holland. Yet it never gave me solutions, just a lot of things to
check and change and fiddle with - without knowing which one to choose
first, and how much it would help.

The YAPP method works. There are cases where it is not 100% accurate. In
most cases it's spot on. Watch where the monitoring tools are going.
Spotlight in the latest edition have the YAPP method built in. Let's see
what Oracle does in 10i. Precise has it. Steve Adams' scripts has it.

This is not about the BCHR being low or high or in between. This is
about using a METHOD instead of 100s of different numbers that don't
mean anything.

Mogens

Rajesh.Rao@jpmchase.com wrote:

  
I too think the BCHR has its place, as a problem indicator. It can tell me
theres something wrong with my database. Say, I have this database
performing well, the users are happy, the BHR is mostly at 90%, and now it
suddenly shoots down to 70%, or it suddenly increases to 98. Somethings
amiss. Its less tasking, to code for scripts that query v$sysstat to
indicate me of some problems, rather than querying v$sqlarea. Or I need to
code for some intelligent scripts to query v$session_wait or
V$system_event. Or I need to look at the statspack reports every hour. The
point is when do I look at wait events? When the user calls me up?

All the papers out there, asking us rightly, to look at wait events, trash
the BCHR. I think what the authors intended was to tell us that increasing
DB_BLOCK_BUFFERS was not the solution to a low BCHR, and that a BCHR of 
    
99%
  
does not mean a highly efficient database. Vice Versa, a BCHR of 50% does
not indicate a poorly performing database. Give me a database with a 45%
BHR, and I can get it to 99% by running a few queries. Point well
understood. It does not mean in any way that I should now ignore PIO's and
start tuning LIO's.

I still use BCHR. "What you infer from the BCHR is what counts".

Raj






    
   
  
                   "Yechiel 
    
   
  
                   Adar"                To:     Multiple recipients of 
    
list ORACLE-L <ORACLE-L@fatcity.com>
  
                   <adar76@inter        cc: 
                   .net.il>             Subject:     Re: BCHR Tuning 
                   Sent by: 
    
   
  
                   root@fatcity. 
    
   
  
                   com 
    
   
  
   
  
   
  
                   January 13, 
    
   
  
                   2003 10:58 AM 
    
   
  
                   Please 
    
   
  
                   respond to 
    
   
  
                   ORACLE-L 
    
   
  
   
  
   
  


Hello Anjo

I just had a tuning session with Dov Hit, from ACS in Israel.
He used some of the scripts that you showed him 2 years ago when you did
some work for Amdocs.
Anyway, after doing some search on the waits, he checked the BCHR and 
    
found
  
out that this database has only 40%. That led us on further checks and we
found more offending SQL's.

The BCHR has it's place.
Just do not measure yourself JUST by it.


Yechiel Adar
Mehish
----- Original Message -----
To: Multiple recipients of list ORACLE-L <ORACLE-L@fatcity.com>
Sent: Monday, January 13, 2003 3:03 AM




    
Hmm,

Lately? That actually started publicly in 1998 as far as I am concerned


      
;-)


    
And acutally long before that.

Anjo.

----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <ORACLE-L@fatcity.com>
Sent: Sunday, January 12, 2003 11:43 PM




      
On Friday 10 January 2003 14:48, Mogens Norgaard wrote:


        
Obviously, we don't know what we're talking about. I can see there's


          
a


    
presentation by Rich Niemich at IOUG-A where he'll address all those
idiots who are saying you should ignore the Cash Hit Ratio (and who


          
are


    
all just after making big money on their products - I loved that


          
one).


    
Or modify the set up of these tools to take action when BCHR


            
falls......


      
Here's the session info:

Date: Mon, Apr 28, 2003 @ 11:45 AM - 12:15 PM
Venue: Southern Hemisphere 2, Walt Disney World
      Dolphin, Lake Buena Vista, FL

Abstract: Lately, there has been a big push to ignore your
hit ratio with claims that it is meaningless. This shallow
minded view (usually by people who sell a tuning tool) ignores
why people look at hit ratios and what they are looking for.
This quick tip talk will show you what to look for and why.
You will definitely know when, where & why to look at your
hit ratio in the future.

Show you why your hit ratio matters. How to analyze the
hit ratio. Fallacies by those who want to sell you products
and tools instead.


Shallow Minded ?!

Jared
--


        



    

 << File: ATT00021.htm >>

--------------080006000809020802030100-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= INET: mln@miracleas.dk 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).