发现个library cache LOCK AND library cache pin 等待事件

首先 库位分析库 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 。。。。。。