Re: Cache Hit Ratio from system views

"Bob Jones" <email_at_me.not> wrote in message news:mOnAi.236$ZA5.16_at_nlpi068.nbdc.sbc.com...
>
> "Richard Foote" <richard.foote_at_nospam.bigpond.com> wrote in message
> news:2_Wyi.24466$4A1.1328_at_news-server.bigpond.net.au...
>>
>> "Bob Jones" <email_at_me.not> wrote in message
>> news:kOtyi.50198$YL5.8637_at_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 ...

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 ?

Cheers

Richard Received on Mon Aug 27 2007 - 08:22:32 CDT