WAITEVENT: "library cache pin" Reference Note (文档 ID 34579.1)

"library cache pin" Reference Note

This is a reference note for the wait event  "library cache pin" which includes the following subsections:

• Brief definition
• Individual wait details (eg: For waits seen in <<View:V$SESSION_WAIT>>)
• Systemwide wait details (eg: For waits seen in <<View:V$SYSTEM_EVENT>>)
• Reducing waits / wait times
• Known Bugs

See  Note:61998.1 for an introduction to Wait Events.

Definition:

• Versions:7.0 - 11.1 Documentation: 11g 10.2
• Library cache pins are used to manage library cache concurrency. 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.

Individual Waits:

  Parameters:

• P1 = Handle address
• P2 = Pin address
• P3 = Encoded Mode & Namespace

• Handle address

  Use  P1RAW rather than  P1
  This is the handle of the library cache object which the waiting session wants to acquire a pin on. 
  The actual object being waited on can be found using

    SELECT kglnaown "Owner", kglnaobj "Object"
      FROM x$kglob
     WHERE kglhdadr='&P1RAW'
    ;

• Pin address

  Use  P2RAW rather than  P2
  This is the address of the PIN itself.

• Encoded Mode & Namespace

  In Oracle 7.0 - 8.1.7 inclusive the value is  10 * Mode + Namespace. 
  In Oracle 9.0 - 11.1 inclusive the value is  100 * Mode + Namespace. 
  
  Where:
  
  Mode is the mode in which the pin is wanted. This is a number thus:

  • 2 - Share mode
  • 3 - Exclusive mode

  
  Namespace is just the namespace number of the namespace in the library cache in which the required object lives:

  • 0 SQL Area
  • 1 Table / Procedure / Function / Package Header
  • 2 Package Body
  • 3 Trigger
  • 4 Index
  • 5 Cluster
  • 6 Object
  • 7 Pipe
  • 13 Java Source
  • 14 Java Resource
  • 32 Java Data

  Wait Time:

The waiter waits up to 3 seconds (1 second if PMON) for the PIN to become available. If not available then the session waits again, incrementing  SEQ# in <<View:V$SESSION_WAIT>> .

  Finding Blockers:

The following SQL can be used to show the sessions which are holding and/or requesting pins on the object that given in  P1 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.

Diagnosis of why there is a blocking scenario will usually need help from Oracle support. If you just want to clear the immediate issue then the SID information above should allow you to kill off any blocking sessions. Proper diagnosis will usually require you to collect 3 SYSTEMSTATE and/or HANGANALYZE dumps at 30 seconds intervals then submit these to Oracle support with full details of the sessions and objects involved. To take a SYSTEMSTATE or HANGANALYZE dump connect to the instance as a user withALTER SYSTEM privilege and issue the command:

  ALTER SESSION SET max_dump_file_size = UNLIMITED;
  ALTER SYSTEM SET EVENTS 'immediate trace name systemstate level 266';

This will produce a trace file under the DIAGNOSTIC_DEST in 11g, or in the USER_DUMP_DEST in earlier releases (or BACKGROUND_DUMP_DEST if connected to a shared server).
In a Parallel Server or RAC environments SYSTEMSTATE dumps should be taken 3 times on each node.

Systemwide Waits:

If "library cache pin" waits form a significant amount of the wait time then it is important to determine if this is one or two sessions waiting long periods of time or a more serious general contention issue among lots of processes.

• Use <<View:V$SESSION_EVENT>> to see if the waits are across numerous sessions or isolated to one or two.
• Use sampling of <<View:V$SESSION_WAIT>> to see if the waits are always for a particular object (ie: a particular value ofP1RAW)
• Use <<View:V$SQLAREA>> to see if any statements have high values of LOADS as repeatedly reloading requires the pin in EXCLUSIVE mode.
• Sometime tracing user sessions which encounter waits can help (See Note:62160.1)

Reducing Waits / Wait times:

What to do to reduce these waits depends heavily on what blocking scenario is occuring. A common problem scenario is the use of DYNAMIC SQL from within PLSQL procedure where the PLSQL code is recompiled and the DYNAMIC SQL calls something which depends on the calling procedure.

• If there is general widespread waiting then the shared pool may need tuning. See Note:62143.1.
• If there is a blocking scenario collect evidence as described in Finding blockers above and contact Oracle support.

Known Bugs

You can restrict the list below to issues likely to affect one of the following versions by clicking the relevant button: 
                     

NB	Bug	Fixed	Description
	13851078	11.2.0.3.BP07, 11.2.0.4, 12.1.0.1	PQ hang for SQL using PLSQL function can deadlock (waits for a "library cache pin")
	13624984	11.2.0.3.4, 11.2.0.3.BP10, 11.2.0.4, 12.1.0.1	IMPDP or IMP hangs on compilation of PLSQL containing a pipelined function
	12411746	11.2.0.3.BP16, 11.2.0.4, 12.1.0.1	RAC waits for "library cache pin" do not time out (do not trigger ORA-4021)
	10138929	11.2.0.3, 12.1.0.1	ORA-600 [17069] in replication receiver / self deadlock on replication internal package
	9327929	11.2.0.2	ORA-600 [kglLockOwnersListDelete] / DIRECTORY object waits using EXTERNAL tables
	6618312	11.1.0.7, 11.2.0.1	Deadlock between ON COMMIT materialized view refresh and query rewrite (library cache pin V lock deadlock)
	6475688	11.1.0.7, 11.2.0.1	Concurrent rewrite and on-commit refresh can deadlock (library cache pin <--> lock)
	6644122	10.2.0.5, 11.1.0.7	ON COMMIT refresh deadlock (library cache pin V lock)
	5604698	10.2.0.4, 11.1.0.6	Deadlock between 'library cache lock' and 'library cache pin' using replication
	7226463	10.2.0.5	EXECUTE IMMEDIATE no releasing mutex or library cache pin
	3717619	9.2.0.6, 10.1.0.4, 10.2.0.1	Deadlock/hang possible due to concurrent cursor loads referencing same INVALID trigger
	3605165	9.2.0.6, 10.1.0.4, 10.2.0.1	Hang/deadlock between sessions concurrently loading a cursor with INVALID trigger
	3374640	10.1.0.3, 10.2.0.1	Create local partitioned domain index can hang
	3253770	9.2.0.6, 10.1.0.3, 10.2.0.1	ORA-4021 / "library cache pin" waits on RAC executing Java stored procedures
+	2968709	9.2.0.5, 10.1.0.2	High "library cache pin" waits possible
	3371003	9.2.0.6	Logical standby apply hang (library cache pin waits)
	3352902	9.2.0.6	Logical apply may hang (library cache pin)

• '*' indicates that an alert exists for that issue.
• '+' indicates a particularly notable issue / bug.
• 'I' indicates an install issue / bug included for completeness.
• 'P' indicates a port specific bug.
• "OERI:xxxx" may be used as shorthand for ORA-600 [xxxx].

Related:

Tracing User sessions  Note:62160.1 
Shared Pool Tuning  Note:62143.1 

Important:

The above text makes reference to some  X$ views. These are only visible to the  SYS user and are not guaranteed to be available on all versions of Oracle. Customers are advised  NOT to have any application code or scripts which rely on any  X$ view.

---

相关内容

产品

• Oracle Database Products > Oracle Database > Oracle Database > Oracle Database - Enterprise Edition > RDBMS

关键字

BUGTAG_ADDBUGS