Library cache pins are used to manage library cache concurrence. Pinning an object causes the heaps to be loaded into memory (if not already loaded). PINS can be acquired in NULL, SHARE or EXCLUSIVE modes and can be considered like a special form of lock. A wait for a “library cache pin” implies some other session holds that PIN in an incompatible mode.
Solutions
Solution: If this is the case, the shared pool may need tuning. See Metalink Note:62143.1.
Problem: If the wait only appears on one or two sessions, the locking scenario is session specific. Collect the following evidence and contact Oracle support.
At a time when a wait is occurring:
select P1RAW from V$SESSION_WAIT where EVENT = ‘library cache pin’
Use the P1RAW value for the following query to determine the object being waited on:
SELECT kglnaown “Owner”, kglnaobj “Object”
FROM x$kglob
WHERE kglhdadr=’&P1RAW’
The following SQL can be used to show the sessions that are holding and/or requesting pins on the object that given in P1RAW in the wait:
SELECT s.sid, kglpnmod “Mode”, kglpnreq “Req”
FROM x$kglpn p, v$session s
WHERE p.kglpnuse=s.saddr
AND kglpnhdl=’&P1RAW’
– An X request (3) will be blocked by any pins held S mode (2) on the object.
– An S request (2) will be blocked by any X mode (3) pin held, or may queue behind some other X request.
This information can be used to identify the blocker and kill the session for a quick fix.
Comment