library cache lock事件【10G】实验

一.老盖那里看来的两个过程

create or replace procedure aiki.calling

is
begin
pining;
dbms_lock.sleep(3000);

end;

CREATE OR REPLACE PROCEDURE AIKI.pining
IS
BEGIN
NULL;
END;

二.执行3个会话

session 1 ---sid=188

SQL> exec calling;

 session 2  ---sid=183

alter procedure calling compile;

session 3 --sid=214

alter procedure calling compile;

三。查询结果

select * from v$session where sid in (214,183,188)

SADDREVENTSIDLAST_CALL_ETSERIAL#0000000084C5DB58library cache pin1838653050000000084C64070PL/SQL lock timer1882168174490000000084C84E20library cache lock214943093

从上图可以看到session2执行时出现的EVENT是library cache pin，而SESSION3则会出现

library cache lock,这就意味着SESSION3想获取在2上的此文件手柄的锁，而2则在等待1完成

完成将对象PIN到内存中，也就是先获得CACHE LOCK锁后再进行PIN操作；

四。查询SID,SADDR信息

select sid,saddr from v$session where event= 'library cache lock';

   214    0000000084C84E20

五。根据SADDR与表中x$kgllk匹配

select kgllkhdl Handle,kgllksnm,kgllkreq Request, kglnaobj Object
from x$kgllk where kgllkses = '0000000084C84E20'
and kgllkreq > 0;

结果:查出处理的对象-》CALLING

HANDLE    KGLLKSNM    REQUEST    OBJECT
  000000007D97FD88    214    3    CALLING

六。通过V$ACCESS来查询被PIN对象当前的持有者SID;

select * from v$access
where object='CALLING'

       SID    OWNER    OBJECT    TYPE
    188    AIKI    CALLING    PROCEDURE

七。KILL该会话了即可解决该等待事件（PIN和LOCK事件）；