发现个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 。。。。。。