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 -