LIBRARY CACHE LOCK 等待事件:
接上篇日志,如果此时再发出一条grant或compile的命令,那么library cache lock等待事件将会出现。
Session 3:
sys@NEI> alter procedure pining compile;
此进程挂起,查询v$session_wait视图可以获得以下信息:
sys@NEI> select * from v$session_wait where event like 'library cache%';
SID SEQ# EVENT P1TEXT P1 P1RAW P2TEXT P2 P2RAW P3TEXT P3
---------- ---------- -------------------- ---------- ---------- -------- ---------- ---------- -------- ---------- ----------
P3RAW WAIT_CLASS_ID WAIT_CLASS# WAIT_CLASS WAIT_TIME SECONDS_IN_WAIT STATE
-------- ------------- ----------- --------------- ---------- --------------- -------------------
142 33 library cache lock handle add 1042613708 3E2505CC lock addre 1090222084 40FB7804 100*mode+n 301
ress ss amespace
0000012D 3875070507 4 Concurrency 0 174 WAITING153 33 library cache pin handle add 1042613708 3E2505CC pin addres 1093359824 412B58D0 100*mode+n 301
ress s amespace
0000012D 3875070507 4 Concurrency 0 210 WAITING
由于handle上的lock已经被Session 2以exclusive模式持有,所以Session 3产生了等待。可以看到,在生产数据库中权限的授予、对象的重新编译可能会导致library cache pin等待的出现,所以应该尽量避免在高峰期进行以上操作。
另外,测试的案例本身就说明:如果Package或过程中存在复杂、交互的依赖关系极易导致library cache pin的出现,所以在应用开发的过程中,也应该注意这方面的内容。
- The End -