作者:dbtan |【转载时请以超链接形式标明文章出处作者信息】


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 WAITING

       153         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 -