oracle library cache pin、library cache lock原理分析。

  oracle  library cache pin、library cache lock原理分析。

   今天是2013-11-2，前段时间一直在研究oracle中复杂的component之shared pool，今天也不例外，对library cache lock、library cache pin进行一下深入的研究，
另外呢，在后边一篇文章也会通过案例来介绍相应的cursor：pin s on wait x等待的原理以及处理办法。
在研究本章内容之前啊，建议懂得一些shared pool的相关知识，我之前写过相关的blog日志，虽然谈不上什么经典，但是也可以帮我提提意见。
  具体参考：
http://blog.csdn.net/xiaohai20102010/article/details/12921645
第一：原理知识：
  1、什么是library cache lock？
  官方文档有如下说明：
This event controls the concurrency between clients of the library cache. It acquires a lock on the object handle so that either:
   One client can prevent other clients from accessing the same object

   The client can maintain a dependency for a long time (for example, no other client can change the object)

This lock is also obtained to locate an object in the library cache.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description
object address Address of the object being loaded
lock address Address of load lock being used
mask Indicates which data pieces of the object that needs to be loaded
翻译一下：在这个library cache lock控制library cache的并发管理，以便。
   1）一个客户端可以阻止其他的客户端访问同一个对象
   2）这个客户端可以长时间的维护一个依赖对象（例如，没有其他用户可以修改该对象）
这种锁在用户试图在library cache中查询定位对象的时候也会获得。对于该锁有三种模式分别是null、share、exclusive，对于该锁的获得等待三秒，一秒用于pmon进程如果超过3秒那么就

会产生等待。
那对于上面说的1和2怎么理解呢？
在我们解析sql或是编译pl/sql语句期间，我们需要获得被应用的数据库对象（表，视图，过程，函数，包，包体，触发器，索引，聚簇，同义词）的library cache lock；这个锁在解析与编

译结束时会被释放。注意：cursor（sql与pl/sql区），管道（pipes）和其他瞬时（transient）对象不适用该锁，library cache lock上的死锁不会被自动检测到，对其的操作是瞎子进行的

。
  2、为什么需要library cache lock
library cache lock是在对象和他们的sql语句之间维持了一种依赖对象机制，假如对象的定义（如字段）被重新定义了或是这个解析锁被“损坏”了，那么依赖对象肯定也失效了，这种维持就

是通过library cache lock实现的。举个例子来说，如果一个表的字段被删除了，那么所有依赖该表的sql将都会变的失效了，必须在下一次访问该 对象的时候重新进行解析，那么library

cache lock就是实现这种机制。而这也是需要有一个队列的，library cache lock是在library cache handle上获得，如果存在不兼容的模式，那么其他的会话必须这时候进行等待。

  3、什么是library cache pin？
官方介绍为：
This event manages library cache concurrency. Pinning an object causes the heaps to be loaded into memory. If a client wants to modify or examine the object, the

client must acquire a pin after the lock.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description
handle address Address of the object being loaded
pin address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is basically a State Object.
mode Indicates which data pieces of the object that needs to be loaded
namespace
翻译一下：
这个library cache pin是维护管理library cache的并发性。在pin一个对象的时候将会把heap载入到内存中，如果一个会话视图编辑或是检查这个对象的时候在获得lock之后必须获得pin。
对于heap怎么理解？它是内存堆，里面包含了很多信息，可以看一下下图就明白了。

 

同样library cache pin也有三种模式分别是null，share、exclusive，当需要访问被缓存到library cache中的数据对象的时候（如，表，索引，聚簇，同义词，视图，过程，包，包体，触

发器、）必须要先pin，当出现library cache pin等待的时候那么这个对象正在被其他会话进行不兼容的模式持有。对于以上的参数，下边会有介绍，就不在这个小命题说了。

 4、我为什么需要library cache pin？

library cache pin是为了处理当前执行依赖对象的，例如，当一个会话在执行访问（sql）这个加载的对象的时候不应该被修改。也就是说，当一个解析锁在没有释放之前，其他会话必须获

得library cache pin 的exclusive模式才能将该对象进行修改。同时，可以想象一个长的sql可能会导致library cache pin的等待。

到了这里我发现，对于library cache 有两种锁，一种为lock另一种是pin，lock是存在于library cache object handle上的，而pin是为了在内存堆维持object的一致性。oracle在sql解析

或是编译对象的时候需要获得library cache lock和library cache pin，防止其他会话对执行的sql对象进行修改。另外在sql的硬解析的时候会获得library cache lock，阻止其他会话对对

象的修改，那么其他会话就会发生等待。

5、什么是library cache load lock？
官方解释：
The session tries to find the load lock for the database object so that it can load the object. The load lock is always obtained in Exclusive mode, so that no other

process can load the same object. If the load lock is busy the session will wait on this event until the lock becomes available.

Wait Time: 3 seconds (1 second for PMON)

Parameter Description
object address Address of the object being loaded
lock address Address of load lock being used
mask Indicates which data pieces of the object that needs to be loaded
这种锁一般发生在编译和重新编译对象的时候出现，如果我试图重新编译一个失效的对象，而这个对象正好也被其他会话给pin住了，那么会产生错误。

第二、参数分析以及咋去查？

1、x$kgllk, x$kglpn and x$kglob
x$kgllk:kernal general library lock
x$kglpn ：kernel general library pin
x$kglob:kernel general library object
查看相关结构
x$kgllk is externalizing all locking structures on an object. Entries in x$kglob acts as a resource structure. x$kglpn is externalizing all library cache pins.
对于该类视图字段，我就是猜，如x$kgllk 中的inst_id代表实例号，kgllkadr代表锁的地址，kgllkuse代表持有该锁的用户，kgllkses代表会话sid，kgllksnm代表这个锁的命名空间，

kgllkhdl代表锁定的handle地址也就是library cache object handle地址，kgllkmod代表锁的模式，kgllkreq代表需要请求的锁的类型，kgllksqlid代表该锁被sql持有的sqlid，user_name

代表用户名等。对于x$kglob和x$kglpn每个字段也是同样的方法，他们的默写字段都是可以和其他会话进行关联的，之后会发现。
2、参数分析
对于library cache pin有如下参数：

Parameter Description
handle address Address of the object being loaded
pin address Address of the load lock being used. This is not the same thing as a latch or an enqueue, it is basically a State Object.
mode Indicates which data pieces of the object that needs to be loaded
namespace  namespace&&encoded mode
这三个参数其实以前我就见过就是对应的v$session中字段p1、p2、p3而p1raw代表是p1的十六进制形式p2raw和p3raw都是一样的，需要说明的是v$session中的这三个字段对于不同的情况有不

同的含义，而现在我们在研究library cache pin那么这三个字段表示内容如下：
p1=handle address
p2=pin address
p3=namespace&&encoded mode

对于p1raw可以对应于x$kglob中的KGLHDADR字段x$kglpn中的KGLPNHDL字段，x$kgllk中的KGLLKHDL字段，后边有sql关联。
对于p2raw代表pin它自己的地址
对于namespace&&encoded mode有如下内容：
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.
mode 代表这个pin需要获得什么样的锁。
2：代表shared mode
3：代表exclusive mode
namespace仅仅是一个在library cache的namespace的数值，其中每个数值含义如下:
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
3、诊断方式
常见的情况有如下两项：往往对于这种诊断可以更加准确的确定问题。
1）当我在一个对象上执行dml语句的时候，其他会话正在视图改变该表的定义，如alter table xxxx modify等，这个时候dml就会被hang住，需要等待的时间根据这个表的大小不同而不同。
这个时候我在v$lock视图上会看到LMODE=6, TYPE=TM 并且id1也指向了操作的object_id,并且还有其他session的等待获取锁的信息。
2）当我们在编译一个procedure或是packet的时候，会获得library cache lock以及library cache pin，其他会话去使用它们，那么这个时候也是会产生等待。
第一种去诊断的方式是通过oradebug进行查看信息或是通过alter system set events 'immediate trace name systemstat level 10';来进行查看内部信息：
注意：
As systemstate dumps are instance specific, they tend to be
inconclusive with hanging problems involving Oracle Parallel Server
(OPS) unless you get them from each node. You will need 3 system state
dumps from each node for OPS.
eg：
SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug dump systemstate 266;
Statement processed.
SQL>
第二种去诊断的方式就是查看x$kgllk,x$kglob,x$kglpn,以及通过这些视图和其他视图进行关联获得想要信息。

第三、学以致用

模拟过程：
首先创建一个存储过程：
SQL> create or replace procedure rhys (amy_sleep in boolean,rhys_compile in boolean)
  2  as
  3  begin
  4  if(amy_sleep) then
  5  dbms_lock.sleep(3000);
  6  elsif(rhys_compile) then
  7  execute immediate 'alter procedure rhys compile';
  8  end if;
  9  end;
 10  /

Procedure created.

SQL>
SQL>
session 1：

SQL> select * from v$mystat where rownuM<2;

       SID STATISTIC#      VALUE
---------- ---------- ----------
        22          0          0

SQL> execute rhys(true,false);

处于等待状态：

session 2：

SQL> select * from v$mystat where rownuM<2;

       SID STATISTIC#      VALUE
---------- ---------- ----------
        42          0          0

SQL> execute rhys(false ,true);

处于等待状态

产生是否有等待时间

SQL>  select sid,username,sql_id,event,p1,p1raw,p2,p2raw,p3,p3raw,wait_time,seconds_in_wait from v$session where event='library cache pin';

       SID USERNAME   SQL_ID        EVENT                        P1 P1RAW                    P2 P2RAW                    P3 P3RAW             WAIT_TIME SECONDS_IN_WAIT
---------- ---------- ------------- -------------------- ---------- ---------------- ---------- ---------------- ---------- ---------------- ---------- ---------------
        42 SYS        2yv7ja732z3p0 library cache pin    2024609840 0000000078AD1830 2123642056 000000007E9434C8 4.0490E+14 0001704200010003          0              10

SQL> r
  1*  select sid,username,sql_id,event,p1,p1raw,p2,p2raw,p3,p3raw,wait_time,seconds_in_wait from v$session where event='library cache pin'

       SID USERNAME   SQL_ID        EVENT                        P1 P1RAW                    P2 P2RAW                    P3 P3RAW             WAIT_TIME SECONDS_IN_WAIT
---------- ---------- ------------- -------------------- ---------- ---------------- ---------- ---------------- ---------- ---------------- ---------- ---------------
        42 SYS        2yv7ja732z3p0 library cache pin    2024609840 0000000078AD1830 2123642056 000000007E9434C8 4.0490E+14 0001704200010003          0              15

SQL>
可以看到等待一直在增加。
通过sql_id可以得到sql
SQL> col sql_text for a60
SQL> r
  1* select sql_text,sql_id from v$sqlarea where sql_id='2yv7ja732z3p0'

SQL_TEXT                                                     SQL_ID
------------------------------------------------------------ -------------
alter procedure rhys compile                                 2yv7ja732z3p0

SQL>

获得锁定 信息：
方法一）
下面通过oradebug查看内容：

SQL> oradebug setmypid
Statement processed.
SQL> oradebug unlimit
Statement processed.
SQL> oradebug dump  systemstate 266
Statement processed.
SQL> @trace.sql

TRACE_FILE_NAME
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

---------------------------------
/opt/app/oracle/diag/rdbms/rhys/RHYS/trace/RHYS_ora_1759.trc

SQL>
查看日志发现：
 
 client details:
      O/S info: user: oracle, term: pts/2, ospid: 1929
      machine: oracle-one program: sqlplus@oracle-one (TNS V1-V3)
      application name: sqlplus@oracle-one (TNS V1-V3), hash value=632623916
    Current Wait Stack:
     0: waiting for 'library cache pin'
        handle address=0x78ad1830, pin address=0x7e9434c8, 100*mode+namespace=0x1704200010003
        wait_id=21 seq_num=22 snap_id=1
        wait times: snap=9 min 31 sec, exc=9 min 31 sec, total=9 min 31 sec
        wait times: max=15 min 0 sec, heur=9 min 31 sec
        wait counts: calls=192 os=192
        in_wait=1 iflags=0x15a2
    There is at least one session blocking this session.
      Dumping 2 direct blocker(s):
        inst: 1, sid: 42, ser: 49
        inst: 1, sid: 22, ser: 27
      Dumping final blocker:
        inst: 1, sid: 42, ser: 49
    There are 0 sessions blocked by this session.
    Dumping one waiter:
      inst: 1, sid: 42, ser: 49
      wait event: 'library cache pin'
        p1: 'handle address'=0x78ad1830
        p2: 'pin address'=0x7e9434c8
        p3: '100*mode+namespace'=0x1704200010003
      row_wait_obj#: 5541, block#: 11545, row#: 0, file# 1
      min_blocked_time: 569 secs, waiter_cache_ver: 757
    Wait State:
      fixed_waits=0 flags=0x22 boundary=(nil)/-1

查看内存信息：

alter system set events 'immediate trace name library_cache level 4';
方法二：
select  a.event,
         a.sid,
         a.SERIAL#,
         a.username,
         a.machine,
         a.wait_time       wt,
         a.seconds_in_wait sw,
         a.state,
         p.kglpncnt,
         p.kglpnmod,
         p.kglpnreq,
         b.kglnaown,
         b.kglnaobj,
         b.kglfnobj,
         b.kglhdobj
    from v$session a, x$kglpn p, x$kglob b
   where p.kglpnhdl in (select kglpnhdl  from x$kglpn where kglpnreq <>0)
      and p.kglpnhdl=b.kglhdadr
      and a.P1RAW=rawtohex(p.kglpnhdl)

 order by seconds_in_wait desc ；
刚刚开始其实我关联的是x$kglob,x$kglpn和v$session视图，但是发现这三个视图关联起来执行速度非常慢。
原因如下：
SQL> select * from v$session;
Elapsed: 00:00:00.02

Execution Plan
----------------------------------------------------------
Plan hash value: 644658511

---------------------------------------------------------------------------------------------
| Id  | Operation                 | Name            | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT          |                 |     1 |  1378 |     0   (0)| 00:00:01 |
|   1 |  NESTED LOOPS             |                 |     1 |  1378 |     0   (0)| 00:00:01 |
|   2 |   NESTED LOOPS            |                 |     1 |  1169 |     0   (0)| 00:00:01 |
|*  3 |    FIXED TABLE FULL       | X$KSUSE         |     1 |  1008 |     0   (0)| 00:00:01 |
|*  4 |    FIXED TABLE FIXED INDEX| X$KSLWT (ind:1) |     1 |   161 |     0   (0)| 00:00:01 |
|*  5 |   FIXED TABLE FIXED INDEX | X$KSLED (ind:2) |     1 |   209 |     0   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   3 - filter("S"."INST_ID"=USERENV('INSTANCE') AND BITAND("S"."KSSPAFLG",1)<>0 AND
              BITAND("S"."KSUSEFLG",1)<>0)
   4 - filter("S"."INDX"="W"."KSLWTSID")
   5 - filter("W"."KSLWTEVT"="E"."INDX")
那么在对v$session查询的时候实际上是在查询x$ksuse,x$kslwt,x$ksled这三个表。倒不如直接把v$session分开。

SQL> select distinct ses.ksusenum      sid,
  2                  ses.ksuseser      serial#,
  3                  ses.ksuudlna      username,
  4                  ses.ksuseunm      machine,
  5                  ob.kglnaown       obj_owner,
  6                  ob.kglnaobj       obj_name,
  7                  pn.kglpncnt       pin_cnt,
  8                  pn.kglpnmod       pin_mode,
  9                  pn.kglpnreq       pin_req,
 10                  w.state,
 11                  w.event,
 12                  w.wait_Time,
 13                  w.seconds_in_Wait
 14    from x$kglpn pn, x$kglob ob, x$ksuse ses, v$session_wait w
 15   where pn.kglpnhdl in (select kglpnhdl from x$kglpn where kglpnreq > 0)
 16     and ob.kglhdadr = pn.kglpnhdl
 17     and pn.kglpnuse = ses.addr
 18     and w.sid = ses.indx
 19   order by seconds_in_wait desc
 20  ;
 
       SID    SERIAL# USERN MACHINE OBJ_O OBJ_NA    PIN_CNT   PIN_MODE    PIN_REQ STATE               EVENT                 WAIT_TIME SECONDS_IN_WAIT
---------- ---------- ----- ------- ----- ------ ---------- ---------- ---------- ------------------- -------------------- ---------- ---------------
        22         27 SYS   oracle  SYS   RHYS            3          2          0 WAITING             PL/SQL lock timer             0             875
        42         49 SYS   oracle  SYS   RHYS            0          0          3 WAITING             library cache pin             0             868
        42         49 SYS   oracle  SYS   RHYS            3          2          0 WAITING             library cache pin             0             868
 
SQL>

查看堵塞sql信息如下：

select sql_text
  from v$sqlarea
 where (v$sqlarea.address, v$sqlarea.hash_value) in
       (select sql_address, sql_hash_value
          from v$session
         where sid in (select sid
                         from v$session a, x$kglpn b
                        where a.saddr = b.kglpnuse
                          and b.kglpnmod <> 0
                          and b.kglpnhdl in
                              (select p1raw
                                 from v$session_wait
                                where event like 'library%')));

获得堵塞会话sql如下：

select distinct ses.ksusenum      sid,
                ses.ksuseser      serial#,
                ses.ksuudlna      username,
                ses.ksuseunm      machine,
                ob.kglnaown       obj_owner,
                ob.kglnaobj       obj_name,
                pn.kglpncnt       pin_cnt,
                pn.kglpnmod       pin_mode,
                pn.kglpnreq       pin_req,
                w.state,
                w.event,
                w.wait_Time,
                w.seconds_in_Wait
  from x$kglpn pn, x$kglob ob, x$ksuse ses, v$session_wait w
 where pn.kglpnhdl in (select kglpnhdl from x$kglpn where kglpnreq > 0)
   and ob.kglhdadr = pn.kglpnhdl
   and pn.kglpnuse = ses.addr
   and w.sid = ses.indx
 order by seconds_in_wait desc;

可以看到会话2（sid为42）正在等待获得pin（exclusive），但是会话1（sid22正好获得了该对象的pin（share），因此library cache pin就产生了。

在会话 三：
SQL> select * from v$mystat where rownum<2;

       SID STATISTIC#      VALUE
---------- ---------- ----------
        46          0          0

 

SQL> execute rhys(true,false);

 

查询结果如下：
 
 
       SID    SERIAL# USERN MACHINE OBJ_O OBJ_NA    PIN_CNT   PIN_MODE    PIN_REQ STATE               EVENT                 WAIT_TIME SECONDS_IN_WAIT
---------- ---------- ----- ------- ----- ------ ---------- ---------- ---------- ------------------- -------------------- ---------- ---------------
        22         27 SYS   oracle  SYS   RHYS            3          2          0 WAITING             PL/SQL lock timer             0            2361
        42         49 SYS   oracle  SYS   RHYS            0          0          3 WAITING             library cache pin             0              19
        42         49 SYS   oracle  SYS   RHYS            3          2          0 WAITING             library cache pin             0              19
        46         11 SYS   oracle  SYS   RHYS            0          0          2 WAITING             library cache pin             0               4
 
SQL>
可以看到pin在rhys上的sid为22持有share pin，在42请求获得exclusive pin，46请求获得share pin。
 在session 4执行：

SQL> execute rhys(true,false);
如何我在session 5执行：
 execute rhys(false ,true);

       SID    SERIAL# USERN MACHINE OBJ_O OBJ_NA    PIN_CNT   PIN_MODE    PIN_REQ STATE               EVENT                 WAIT_TIME SECONDS_IN_WAIT
---------- ---------- ----- ------- ----- ------ ---------- ---------- ---------- ------------------- -------------------- ---------- ---------------
        22         27 SYS   oracle  SYS   RHYS            3          2          0 WAITING             PL/SQL lock timer             0            2537
        42         49 SYS   oracle  SYS   RHYS            0          0          3 WAITING             library cache pin             0             195
        42         49 SYS   oracle  SYS   RHYS            3          2          0 WAITING             library cache pin             0             195
        46         11 SYS   oracle  SYS   RHYS            3          2          0 WAITING             PL/SQL lock timer             0             165
        48         11 SYS   oracle  SYS   RHYS            3          2          0 WAITING             PL/SQL lock timer             0              58
        43         29 SYS   oracle  SYS   RHYS            3          2          0 WAITING             library cache lock            0               0
 
6 rows selected
那么这时session5就会请求library cache lock。

如何降低library cache lock？
我们首先要确认的是 library cache 的竞争是整个系统层面的还是只发生在某个或某些 SQL 语句上。这个"library cache lock"是被一个特定的 SQL 持有很长的时间吗？或者总是在等待某

个特定的对象？还是说这个锁在短时间内被请求的次数很多从而造成的竞争？

如果问题是在整个系统层面发生的，一般来说是由于 shared pool 太小或 SQL 语句不共享造成的。一些解决竞争的方法：

增大 shared pool 从而减少 reload 的次数，这是因为 shared pool 过小会造成获取锁的时间加长。

通过将 cursor_sharing 设置为 similar 或 force 来使 SQL 语句共享。
需要小心的是这样做可能会改变SQL的执行计划，所以做之前需要做完整的测试。

在系统不繁忙的时候做统计信息的收集或其它维护作业，从而降低无效化（invalidation）的次数。
如何降低library cache pin
如果"library cache pin"等待的时间很长那么很重要的一点就是判断是只有一两个 process 在等待还是有很多的 process 都在等待。

如果说只是一两个 process 被另一个 process 阻塞的话，那么需要检查持有这个 pin 的 process 为什么这么长时间不释放。

如果说等待是大范围的那么说明 shared pool 需要优化
参考：
http://orainternals.wordpress.com/2009/06/02/library-cache-lock-and-library-cache-pin-waits/

如下是一些已知的bug:

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
	5650841		Hang / deadlock from ANALYZE of cluster index
	16191248	12.1.0.1.1, 12.1.0.2, 12.2.0.0	Hang from concurrent drop of on-commit materialized views or using DBMS_REDEFINITION
	14295250	11.2.0.4, 12.1.0.1	Long parse time for large query with many nested views due to much time in epxression analysis code
	14191508	11.2.0.3.8, 11.2.0.3.BP16, 11.2.0.4, 12.1.0.1	Slow row cache load due to SEG$ and INDSUBPART$ queries
	14176247	11.2.0.4, 12.1.0.1	Many child cursors using Adaptive Cursor Sharing with binds (due to BIND_EQUIV_FAILURE)
	15850031	11.2.0.4, 12.2.0.0	Rare instance hang: deadlock between 'row cache lock' and 'cursor: pin S wait for X'
	14469756	12.2.0.0	Partition pruning causes delay in TBL$OR$IDX$PART$NUM
	14302813	11.2.0.4, 12.2.0.0	QC blocked / parse hang for parallel DML executed from remote stored procedure
	14029891	11.2.0.4, 12.1.0.1	mutex deadlock having SQL baselines on recursive dictionary cursor
	11927619	11.2.0.1.BP11, 11.2.0.2.BP07, 11.2.0.3, 12.1.0.1	DBMS_STATS slow on interval composite partitions
	11855965	11.2.0.3, 12.1.0.1	Truncate partition takes long time doing recursive delete on MLOG$
	10213073	11.2.0.2.8, 11.2.0.2.BP18, 11.2.0.3, 12.1.0.1	CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects
	10171273	11.2.0.2.8, 11.2.0.2.BP08, 11.2.0.3, 12.1.0.1	Long parse time with non-equi subpartitioning under interval partitioning
	9944129	11.2.0.1.BP12, 11.2.0.2, 12.1.0.1	SQL not shared due to INST_DRTLD_MISMATCH with global transaction
	9935787	11.2.0.3, 12.1.0.1	Long parse time for large inlists - can cause 'cursor: pin S wait on X' waits
	9694101	10.2.0.5.7, 11.2.0.2, 12.1.0.1	Hang / deadlock between "cursor: pin S wait on X" and "library cache lock" involving dictionary objects
	9499302	10.2.0.5.5, 11.1.0.7.7, 11.2.0.1.BP08, 11.2.0.2, 12.1.0.1	Improve concurrent mutex request handling
	9472669	11.2.0.1.BP12, 11.2.0.2, 12.1.0.1	'cursor: pin S wait on X' waits for invalid SQL over DB link
	8508078	11.2.0.2, 12.1.0.1	Contention from many concurrent bad SQLs - superseded
	12432089	11.2.0.3	library cache lock/cursor: pin s wait on x with parallel partition stats gatheri
	8441239	11.2.0.1	Library cache lock waits if long running TRUNCATE in progress
	8348464	11.1.0.7.2, 11.2.0.1	CREATE SYNONYM and CREATE PACKAGE may incorrectly invalidate objects
	7234778	11.2.0.1	Unnecessary "cursor: pin S wait on X" waits
	5485914	10.2.0.4	Mutex self deadlock on explain / trace of remote mapped SQL
	6143420	10.2.0.5, 11.1.0.6	Deadlock involving "ROW CACHE LOCK" on dc_users AND "CURSOR: PIN S WAIT ON X"
	6011045	10.2.0.5.5	DBMS_STATS causes deadlock between 'cursor: pin S wait on X' and 'library cache lock'
	7462072	10.2.0.4.3, 10.2.0.5	Unnecessary "cursor: pin S wait on X" waits
	5983020	10.2.0.4	MMON deadlock with user session executing ALTER USER
	7226463	10.2.0.5	EXECUTE IMMEDIATE no releasing mutex or library cache pin
+	5907779	10.2.0.4	Self deadlock hang on "cursor: pin S wait on X" (typically from DBMS_STATS)

• '*' 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.
• Fixed versions use "BPnn" to indicate Exadata bundle nn.
• "OERI:xxxx" may be used as shorthand for ORA-600 [xxxx].