一.老盖那里看来的两个过程
create or replace procedure aiki.calling
isbegin
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)
SADDR | EVENT | SID | LAST_CALL_ET | SERIAL# |
0000000084C5DB58 | library cache pin | 183 | 865 | 305 |
0000000084C64070 | PL/SQL lock timer | 188 | 2168 | 17449 |
0000000084C84E20 | library cache lock | 214 | 9 | 43093 |
从上图可以看到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事件);