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: BCHR Tuning

RE: BCHR Tuning

From: Johnson, Michael <Michael.Johnson_at_oln-afmc.af.mil>
Date: Fri, 31 Jan 2003 13:21:19 -0800
Message-ID: <F001.005410F0.20030131132119@fatcity.com>


Book me on the next flight to Sydney please.

-----Original Message-----
Sent: Monday, January 13, 2003 6:24 PM
To: Multiple recipients of list ORACLE-L

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_at_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_at_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_at_fatcity.com>
> <adar76_at_inter cc:
> .net.il> Subject: Re: BCHR Tuning
> Sent by:
   

> root_at_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_at_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_at_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 >>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: mantfield
  INET: mantfield_at_connexus.net.au

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: Johnson, Michael 
  INET: Michael.Johnson_at_oln-afmc.af.mil

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 Fri Jan 31 2003 - 15:21:19 CST

Original text of this message

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