RE: Statspack ratios help

Generally you want to read from memory rather than disk, but when your BHR is 100%, that is sometimes an indicator that you have some inefficient queries that are doing way too many logical reads, which is usually caused by use of an index where a full scan would be more efficient. It would take more data to confirm this is the case though. A good place to start would be with looking at your top sql by buffer gets (further down in the statspack report) and seeing if they are performing more gets than they should. In this case, it looks like the high BHR is more attributable to the fact that his physical reads are very low (.39/sec), rather than his logical reads being too high, since 26K/sec and 510/transaction isn't really unusual, so he probably just has a small data set that is fitting entirely in memory. Hard to tell anything with certainty from the limited info provided, just some guesses.  

Regards,
Brandon    

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Bryan Wells Sent: Tuesday, June 06, 2006 12:39 PM
To: Oracle-L
Subject: Re: Statspack ratios help

As a Jr. wanting to be Sr. (someday) I have to ask the stupid questions:  

why is Buffer % bad? Dont you want 100% buffer cache hit vs. 100% disk i/o?  

Privileged/Confidential Information may be contained in this message or attachments hereto. Please advise immediately if you or your employer do not consent to Internet email for messages of this kind. Opinions, conclusions and other information in this message that do not relate to the official business of this company shall be understood as neither given nor endorsed by it.

--
http://www.freelists.org/webpage/oracle-l