Path: text.usenetserver.com!out02b.usenetserver.com!news.usenetserver.com!in04.usenetserver.com!news.usenetserver.com!news.astraweb.com!border1.newsrouter.astraweb.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!news.linkpendium.com!news.linkpendium.com!pit-transit.telstra.net!lon-in.news.telstra.net!news.telstra.net!news-server.bigpond.net.au!53ab2750!not-for-mail
From: "Richard Foote" <richard.foote@nospam.bigpond.com>
Newsgroups: comp.databases.oracle.server
References: <1186588653.996873.185140@l70g2000hse.googlegroups.com>   <1186599766.578604.210630@q75g2000hsh.googlegroups.com>   <nk6kb35l9bpv0mhlpl6bn9f1e1dja3esc8@4ax.com>   <sEPui.56873$5j1.43159@newssvr21.news.prodigy.net>   <q7tnb3h6duhe3apub6iieqv76rrpea4ehk@4ax.com>   <jO8vi.27305$RX.26761@newssvr11.news.prodigy.net>   <1186809197.947956@bubbleator.drizzle.com>   <sIPwi.2089$3x.1702@newssvr25.news.prodigy.net>   <1187292802.754728@bubbleator.drizzle.com>   <Y57xi.245$LL7.216@nlpi069.nbdc.sbc.com>   <_O7xi.60740$vS1.15087@newsfe16.phx>   <eB8xi.1326$i75.244@newssvr19.news.prodigy.net>   <xT8xi.82911$kK1.41582@newsfe14.phx>   <Kt9xi.1328$i75.171@newssvr19.news.prodigy.net> <1187328939.022236.195040@i13g2000prf.googlegroups.com> <kOtyi.50198$YL5.8637@newssvr29.news.prodigy.net> <2_Wyi.24466$4A1.1328@news-server.bigpond.net.au> <mOnAi.236$ZA5.16@nlpi068.nbdc.sbc.com> <seAAi.26732$4A1.22707@news-server.bigpond.net.au> <7d_Ai.4071$JD.3351@newssvr21.news.prodigy.net>
In-Reply-To: <7d_Ai.4071$JD.3351@newssvr21.news.prodigy.net>
Subject: Re: Cache Hit Ratio from system views
Lines: 119
MIME-Version: 1.0
Content-Type: text/plain;
 format=flowed;
 charset="iso-8859-1";
 reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Windows Mail 6.0.6000.16480
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16480
Message-ID: <cXdBi.27614$4A1.19426@news-server.bigpond.net.au>
Date: Wed, 29 Aug 2007 12:49:12 GMT
NNTP-Posting-Host: 124.176.56.99
X-Complaints-To: abuse@bigpond.net.au
X-Trace: news-server.bigpond.net.au 1188391752 124.176.56.99 (Wed, 29 Aug 2007 22:49:12 EST)
NNTP-Posting-Date: Wed, 29 Aug 2007 22:49:12 EST
Organization: BigPond Internet Services
Xref: usenetserver.com comp.databases.oracle.server:434063
X-Received-Date: Wed, 29 Aug 2007 08:50:58 EDT (text.usenetserver.com)

"Bob Jones" <email@me.not> wrote in message 
news:7d_Ai.4071$JD.3351@newssvr21.news.prodigy.net...
>
> "Richard Foote" <richard.foote@nospam.bigpond.com> wrote in message 
> news:seAAi.26732$4A1.22707@news-server.bigpond.net.au...
>> "Bob Jones" <email@me.not> wrote in message 
>> news:mOnAi.236$ZA5.16@nlpi068.nbdc.sbc.com...
>>>
>>> "Richard Foote" <richard.foote@nospam.bigpond.com> wrote in message 
>>> news:2_Wyi.24466$4A1.1328@news-server.bigpond.net.au...
>>>>
>>>> "Bob Jones" <email@me.not> wrote in message 
>>>> news:kOtyi.50198$YL5.8637@newssvr29.news.prodigy.net...
>>>>>
>>>>> High BCHR is always better than low - provided everything else being 
>>>>> equal. If BCHR is useless for the stated reasons, no other indicator 
>>>>> would be useful.
>>>>
>>>> This I'm afraid is where you're fundamentally incorrect.
>>>>
>>>> A high BCHR can mean your database is on life support, struggling to 
>>>> cope with exessive LIOs due to inefficient SQL with users staring at an 
>>>> hourglass rather than returned data.
>>>>
>>>> A BCHR that has increased can mean your database has suddenly hit 
>>>> significant performance issues. Or it can mean things have improved. Or 
>>>> it can mean response times remain unaffected.
>>>>
>>>> A BCHR that has reduced can mean your database has suddenly hit 
>>>> significant performance issues. Or it can mean things have improved 
>>>> (yes, improved because that crippling transaction that was previously 
>>>> performing poorly due to massively exessive LIOs has been fixed, 
>>>> reducing the overall BCHR) . Or it can mean response times remain 
>>>> unaffected.
>>>>
>>>> Not much of an indicator is it ?
>>>>
>>>> But saying that a BCHR is *always* better than a low is just plain 
>>>> wrong wrong wrong ...
>>>>
>>>
>>> Didn't I repeatedly say "provided everything else being equal"?
>>>
>>
>> And how precisely do you determine that everything else indeed is equal ? 
>> Most databases don't exactly remain equal ...
>>
>
> No, they do not. That's why you do not look at BCHR alone, as I have said 
> before.

So what else do you look at in conjunction with the BCHR ?

Interestingly, you never answer any of the questions and you never give any 
examples of why you consider the BCHR to be such a fantastic indicator. And 
yes, I have read *all* your contributions to this discussion ...

So how about you at least attempt to justify your claim that the BCHR is "a 
very meaningful indicator". How do you actually use the BCHR in a meaningful 
manner ? So you look at the BCHR and ..., and what ?

And when do you look at these other "whatevers" in conjunction with the BCHR 
? When the BCHR increases, what else do you check ? And when the BCHR 
decreases, what else do you check and how do these checks differ from when 
the BCHR increases ? And when the BCHR remains the same, what else do you 
check and how do these checks differ from when the BCHR increases or 
decreases ?

Remember, it's your claim that the BCHR is "a very meaningful indicator", 
well show us ?

If you can ....

>
>> And when precisely do you check if everything else is equal with this 
>> "very meaningful indicator" of yours ? When the BCHR increases ? When the 
>> BCHR decreases ? When the BCHR remains the same ?
>>
>
> Try asking yourself the same questions about any other indicators you 
> consider meaningful. The question here is not how to determine if 
> everything else is equal. It is about whether BCHR means anything if 
> everything else is equal.

Please, if everything else is equal, how can the BCHR change ? How can a 
high BCHR always be better than a low BCHR, everything being equal when 
having a higher BCHR can only mean things are not equal by definition, else 
the BCHR would be the same ? Right ?

Can you please explain how this is possible, having a higher BCHR with 
everything being equal, at least attempt some kinda description of what 
"everything else" means, at least attempt to justify this somewhat bizarre 
claim ...

If you can ...

Again I go back to my initial set of questions. If your BCHR were to 
increase from (say) 95% to (say) 99.9%, if this very meaningful indicator 
were to change in this manner, what else do you check to ensure that things 
are really better, that the higher BCHR is actually a good thing, that all 
these mysterious "things" are indeed equal ?

And why wouldn't you need to check these other indicators when the BCHR 
decreases ?

And why wouldn't you need to check these things if the BCHR remains the same 
?

If you can't answer these rather basic questions is a vaguely meaningful 
manner, then ummmm, game over I think.

Go on, answer these questions, dare ya !!

If you can ...

Cheers

Richard 

