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.
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."
BHCR is as worthless as your unwillingness to acknowledge you are wrong.
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.
--
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Received on Thu Sep 06 2007 - 08:52:04 CDT
