Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Cache Hit Ratio from system views

Re: Cache Hit Ratio from system views

From: Bob Jones <email_at_me.not>
Date: Fri, 07 Sep 2007 00:40:20 GMT
Message-ID: <U51Ei.1928$FO2.795@newssvr14.news.prodigy.net>

"DA Morgan" <damorgan_at_psoug.org> wrote in message news:1189086718.413526_at_bubbleator.drizzle.com...

> Bob Jones wrote:
>> "Niall Litchfield" <niall.litchfield_at_gmail.com> wrote in message 
>> news:1188811168.606148.130030_at_k79g2000hse.googlegroups.com...

>>> On 1 Sep, 01:29, "Bob Jones" <em..._at_me.not> wrote:
>>>>> If the BCHR is an objective indicator, please tell us of what you
>>>>> think
>>>>> it is an indicator, and how - specifically you would use it. Richard's
>>>>> indicator (as mine) is how long business transaction take. Definitely
>>>>> objective and relatively straightforward to use and understand.
>>>> BHCR shows disk i/o percentage. An important indicator for buffer cache
>>>> tuning.
>>> So how exactly would you use it? If BCHR falls below a certain value
>>> increase one or more of the pool sizes? If it rises above a certain
>>> value reduce them?
>>>
>>>> As I said before, response time is not even a database metric.
>>> well no it isn't, it's a metric for the measurement of the performance
>>> of the application as experienced by the end-user. Round in my part of
>>> the world we install and use applications to support line of business
>>> transactions and it is those installations that we care about rather
>>> than the individual component. That's the primary reason that a metric
>>> derived from business usage makes most sense to me.
>>>
>>>> It is an effect not a cause.
>>> That's true enough, but breaking down the response time into it's
>>> component parts, say
>>> Time spent at web server
>>> Time spent in application server
>>> Time spent on network
>>> Time spent in DB.
>>>
>>> At a gross level gives you a much better tuning methodology than
>>> requests satisifed from cache for any given component of the stack.
>>> Producing an execution profile for the objects of interest really
>>> shouldn't be news given that it was first described and demonstrated
>>> by Knuth when I was 4 (and I'm ten times that age this year). The more
>>> each of those tiers allow you to break down the response time
>>> components the better you chance of finding the problems.
>>>
>>>> With some people's logic here, even response time is
>>>> meaningless. 5 minutes response time can be better than 5 seconds
>>>> response
>>>> time, if it is doing 5000 times more work.
>>> That would likely depend on your requirements, in Richard's ATM
>>> analogy it would seem unlikely that many banks would prioritise
>>> keeping all their customers waiting 5 minutes to withdraw cash over
>>> allowing a smaller subset to be happy with their 5 second response. On
>>> the other hand if the per customer end of month statement takes 5
>>> seconds, but the batch process for 5000 takes 5 minutes then I know
>>> which I'd be scheduling in my month end process.
>>>
>>
>> You are missing the point of this long thread. To avoid further branching 
>> out to different topics, I would recommend reading it.
>
> No Bob. The only one missing the point, repeatedly, is you.
>
> You have been incorrect, you are incorrect, and given your propensity
> to try to win arguments by virtue of tenacity rather than facts, it
> appears that you always will be incorrect.
>

Someone who has only posted a couple of useless comments in this thread is actually producing facts? Now that's news.

> To quote the Oracle docs:
> "A low cache hit ratio does not imply that increasing the size of the 
> cache would be beneficial for performance. A good cache hit ratio could 
> wrongly indicate that the cache is adequately sized for the workload."
>

Finally, something useful, but quoted from the doc. Notice the words like "could" or "would"?
The second sentence is a little vague. What does "good" mean? Is my cache still too small, if BCHR is 99%?

> BHCR is as worthless as your unwillingness to acknowledge you are wrong. >

I take it our buddy Dan here doesn't tune his buffer cache.

> But given that your name is valid, and your email is not valid, why > would anyone expect your opinion to be valid? Come on out of the closet.

It appears valid names are more important to you than valid arguments. Unlike you, I am not here to promote myself or anybody else. Received on Thu Sep 06 2007 - 19:40:20 CDT

Original text of this message

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