發現個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 。。。。。。