RE: library cache hit ratio > 100% (science fiction answer content free reply)

Well, yesterday Oracle noticed that after you parsed, say, select * from first_view_in_my_report_series, you next parsed select * from second_view_in_my_report_series and Oracle looked at your system statistics and memory usage and figured there was no real cost to parsing it whether you wanted it later or not. Oracle didn't muddy your actual usage statistics with its preemptive guesses, so you got a cache_hit on something you never requested. Your database is really only tuned well if this number approaches infinity, even if it means insisting that your users do exactly what they did yesterday forevermore. If you have any questions about this, please refer to my addition to the subject line.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Jared Still Sent: Monday, March 14, 2005 4:13 PM
To: jhowerton_at_uabmc.edu
Cc: oracle-l_at_freelists.org
Subject: Re: library cache hit ratio > 100%

My guess is that reloads has gone negative.

Which version of Oracle?

Jared

On Mon, 14 Mar 2005 14:47:05 -0600, James Howerton <jhowerton_at_uabmc.edu> wrote:
> DBA's,
>
> Has anyone seen library cache hit ratio > 100% ??? This is a very busy
> production database, it is usually < 97 % ( I don't tune by hit ratios
> I'm just curious).
>
> SQL> select SUM(PINS)/(SUM(PINS)+SUM(RELOADS))*100
> from v$librarycache;
>
> Library Hit Ratio
> --------------------------
> 100.009799
>
> 1 row selected.
>
> TIA
> ...JIM...
> --
> http://www.freelists.org/webpage/oracle-l
>

--
Jared Still
Certifiable Oracle DBA and Part Time Perl Evangelist
--
http://www.freelists.org/webpage/oracle-l


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