Re: Cache Hit Ratio from system views

On Wed, 5 Sep 2007 21:12:05 -0500, "Bob Jones" <email_at_me.not> 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.
>

>You are missing the point of this long thread. To avoid further branching
>out to different topics, I would recommend reading it.
>

This is probably a too difficult task for you, given your closed mind, and your earlier more unprofessional advices, as well as your unprofessional attitude.

-- 
Sybrand Bakker
Senior Oracle DBA