发现个library cache LOCK AND library cache pin 等待事件-优快云博客

探讨了在Oracle10gR2环境中两个并发运行的过程——属性过程和交易过程——之间的阻塞问题。尽管两个过程分别从同一张大表中获取数据并插入不同表中，理论上不应发生冲突，但在实际运行中却出现了交易过程因图书馆缓存锁而被属性过程阻塞的情况。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

首先库位分析库 ORACLE 10G R 2 01 
其次开发了两个过程暂时称为属性过程和交易过程。从同一个大表获取相关的数据然后插入不同的表。应该说该两个过程不锁相关对象！
其二这两个过程测试中都跑的好好的。

后来用TOAD 把过程的运行日志表
ALTER TABLE BA.T_BASE_SP_RUNLOG CACHE; 
ALTER TABLE BA.T_BASE_SP_RUNLOG STORAGE ( BUFFER_POOL KEEP );

没多久其中从EM看到已经有个过程在运行中它是属性过程。再启动交易过程从EM上发现属性过程既然阻塞了交易过程。
交易过程等待事件 LIBCACHE LOCK AND library cache pin

属性过程则是DB FILE 顺序读！

这就很纳闷了，它们虽然同时访问流水表，只是SELECT而已，并不能发生冲突啊！
下面语句看被锁定的对象
select xidusn, object_id, session_id, locked_mode from v$locked_object;

属性过程是151会话在做 update b set time=(select min(addtime) from user_pay_bak where f_username=:B )
只是锁定了B表而已

select * from v$session_wait where sid=64 交易过程 library cache LOCK

交易过程正在等待对象 P_BASE_DAY_I_SPRUN_LOG
SELECT KGLNAOWN,KGLNAOBJ 
FROM x$kglob 
WHERE kglhdadr in( select P1RAW from v$session_wait where sid=64);

而它只是把过程运行的信息写进日志表的过程而已！

属性过程：

update b set time=(select min(addtime) from user_pay_bak where f_username=:B )
前面有四个事务
1 INSERT INTO.... COMMIT; P_BASE_DAY_I_SPRUN_LOG(.....);

2 FOR CUR() LOOP UPDATE B SET CUSTIME=() END LOOP; COMMIT; P_BASE_DAY_I_SPRUN_LOG(.....);
3 FOR CUR() LOOP UPDATE B SET EMAILTIME=() END LOOP; COMMIT; P_BASE_DAY_I_SPRUN_LOG(.....);
4 FOR CUR() LOOP UPDATE B SET MOBILETIME=() END LOOP; COMMIT; P_BASE_DAY_I_SPRUN_LOG(.....);

既然已经执行到第五步：update b set time=(select min(addtime) from user_pay_bak where f_username=:B ) 
那么前面四个应该都执行完了，同时也调用了写日志过程

难道写日志过程被属性过程给霸占不释放吗？
用TOAD 释放运行日志表还是不行，再把交易表终止，再运行也不行。
最后终止属性过程，然后再运行就OK 了

难道表被CACHE 。。。。。。