Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Gets vs pins in v$librarycache

Gets vs pins in v$librarycache

From: yong huang <yong321_at_yahoo.com>
Date: Thu, 25 May 2000 21:59:17 -0700 (PDT)
Message-Id: <10508.106820@fatcity.com>


Can somebody tell me the exact difference between the gets and pins in v$librarycache? The documentation for v$librarycache says:

gets: number of times a lock was requested for objects of this namespace gethits: number of times an object's handle was found in memory pins: number of times a PIN was requested for objects of this namespace pinhits: number of times all of the metadata pieces of the library object were found in memory

Now, let's say the namespace is SQL Area. According to the above description plus these two pages:

http://x75.deja.com/getdoc.xp?AN=621820177&CONTEXT=959316014.2116878342&hitnum=2  and
http://x75.deja.com/getdoc.xp?AN=624407275&search=thread&CONTEXT=959316014.2116878342&HIT_CONTEXT=959316014.2116878342&hitnum=1

, my understanding is: gets is the number of times an oracle process tries to find if a particular SQL statement has been parsed before and left a "mark" in library cache, gethits means yes it has, pins is the number of times an oracle process tries to find all necessary data and code (text in UNIX's terminology?), and pinhits is yes all necessary, ready-to-use data and compiled machine code are found, i.e. they're not flushed out of memory.

Please clarify. If this understanding is correct, I don't understand why the library cache bothers to store just the "mark" or handle to the SQL statement if its parsed, ready-to-use machine code could have been flushed out already. Also I noticed that my pins is much greater, not smaller, than gets.

Yong Huang
yong321_at_yahoo.com



Do You Yahoo!?
Kick off your party with Yahoo! Invites. Received on Thu May 25 2000 - 23:59:17 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US