4.4.2 library cache lock和library cache pin
    在前面的部分我们已经看到了library cache lock和library cache pin的成因，并且也模拟出了这两个等待事件。那么当我们发现在v$session_wait里出现了这两个等待事件中的某一个式时，该怎么办呢？
还是按照上面我们模拟这两个等待事件的例子。这时我们查看v$session_wait，发现出现这两个等待。
 

SQL> select sid,event from v$session_wait where event like 'library%';
SID EVENT
---------- ---------------------------------------------------------------- 
9 library cache pin
10 library cache lock

    这时，我们可以使用如下的SQL语句来获得是哪个session通过哪条SQL语句获得了library cache pin，而哪个session又试图通过哪条SQL语句去申请library cache pin。    

SQL> SELECT distinct
2 decode(kglpnreq,0,'holding_session: ' || s.sid,'waiting_session: ' || s.sid) sid,
3 s.SERIAL#,
4 kglpnmod "Pin-Mode",
5 kglpnreq "Req-Pin",
6 a.sql_text,
7 kglnaown "Owner",
8 kglnaobj "Object"
9 FROM x$kglpn p, v$session s, v$sqlarea a, v$session_wait sw, x$kglob x
10 WHERE p.kglpnuse = s.saddr
11 AND kglpnhdl = sw.p1raw
12 and kglhdadr = sw.p1raw
13 and event = 'library cache pin'
14 and (a.hash_value, a.address) IN
15 (select DECODE(sql_hash_value, 0, prev_hash_value, sql_hash_value),
16 DECODE(sql_hash_value, 0, prev_sql_addr, sql_address)
17 from v$session s2
18 where s2.sid = s.sid);
SID SERIAL# Pin-Mode Req-Pin SQL_TEXT Owner Object
--------------- ------- ------ ------- ------------------------------ ------ ---------- 
holding_session:8 22 2 0 BEGIN lock_test; END; COST LOCK_TEST
waiting_session:9 16 0 3 alter procedure lock_test compile COST LOCK_TEST



 
    
    同样，我们可以使用下面的SQL语句来显示哪个session正持有lock或者pin，而哪个session又在等待lock或者pin。
注意，我们不能获得正在等待lock的session所发出的SQL语句，因为该session都还没
有获得library cache对象句柄的控制权，就更谈不上将SQL语句写入heap里了，所以我们无法获得该session所发出的SQL语句。
因此，我们只能显示哪个session正在等待lock。 

SQL> select /*+ ordered */ 2 w1.sid waiting_session, 3 h1.sid holding_session, 
4 w.kgllktype lock_or_pin, 5 w.kgllkhdl address, 
6 decode(h.kgllkmod,0,'None',1,'Null',2,'Share',3,'Exclusive','Unknown') 
mode_held, 7 decode(w.kgllkreq,0,'None',1,'Null',2,'Share',3,'Exclusive','Unknown') 
mode_requested 8 from dba_kgllock w, dba_kgllock h, v$session w1, v$session h1 9 
where (((h.kgllkmod != 0) and (h.kgllkmod != 1) 10 and ((h.kgllkreq = 0) or (h.kgllkreq = 1))) 11 
and (((w.kgllkmod = 0) or (w.kgllkmod = 1)) 12 and ((w.kgllkreq != 0) and (w.kgllkreq != 1)))) 13 
and w.kgllktype = h.kgllktype 14 and w.kgllkhdl = h.kgllkhdl 15 and w.kgllkuse = w1.saddr 16 
and h.kgllkuse = h1.saddr; WAITING_SESSION HOLDING_SESSION LOCK_OR_PIN ADDRESS MODE_HELD MODE_REQUESTED 
--------------- --------------- ----------- -------- --------- --------------
 9 8 Pin 675C3078 Share Exclusive 10 9 Lock 675C3078 Exclusive Exclusive 

   从上面的结果可以很清楚的看到，sid为8的session阻止了sid为9的session获得pin，而sid为9的session又阻止了sid为10的session获得lock。

    通常，这两个等待都是由于DDL所引起的，因此我们还可以快速的通过查看dba_ddl_lock视图来看当前哪些session正在对表lock_test进行操作。我们可以看到下面的结果中，sid为9的session正以Exclusive模式获得表lock_test，而sid为10的session则正以Exclusive模式申请对该表的lock。

SQL> select session_id,owner,type,mode_held,mode_requested 
2 from dba_ddl_locks where owner='COST' and name='LOCK_TEST'; 
SESSION_ID OWNER TYPE MODE_HELD MODE_REQUESTED 
---------- ------------ -------------------- --------- -------------- 
 8 COST Table/Procedure/Type Null None 
 9 COST Table/Procedure/Type Exclusive None 
 10 COST Table/Procedure/Type None Exclusive