From oracle-l-bounce@freelists.org Mon Mar 14 17:14:34 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j2ENEYZ8026010 for ; Mon, 14 Mar 2005 17:14:34 -0600 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j2ENEYem026006 for ; Mon, 14 Mar 2005 17:14:34 -0600 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4C3DE8652A; Mon, 14 Mar 2005 17:12:55 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08130-02; Mon, 14 Mar 2005 17:12:55 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id C432C867D5; Mon, 14 Mar 2005 17:12:54 -0500 (EST) Message-Id: Date: Mon, 14 Mar 2005 16:10:51 -0600 From: "James Howerton" To: Subject: Re: library cache hit ratio > 100% Mime-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Disposition: inline X-archive-position: 17290 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: jhowerton@uabmc.edu Precedence: normal Reply-To: jhowerton@uabmc.edu X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on air891.startdedicated.com X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=ham version=2.60 X-Spam-Level: Thanks, I forgot about the bugs in 8i x$... If hit ratios were paradise then this would be the fastest db in the land(almost). The application vendor finally certified on 9.2.0.X so I get to drag this database up to only two years behind.;-0 ...JIM... >>> Mladen Gogala 3/14/05 3:24:14 PM >>> James Howerton 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. > > > This is a well known bug from 8i: all quantities in X$ tables are 32-bit and when the database is busy enough, those quantities can turn negative. That is how you get negative reloads. That was limiting usefulness of statspack on 8i, too.Don't worry, be happy, you're living in the database tuner's paradise: BCHR>100%. What else can you ask for? -- Mladen Gogala Oracle DBA Ext. 121 -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l