10g中的transaction等待事件

最近公司資料庫出現了這樣一個現象：
TX enqueue等待佇列很長，而持有鎖的會話所執行UPDATE語句的執行計劃沒有任何問題，執行效率應該很高，但是語句持有鎖的時間卻很長，這些會話的等待事件是transaction，從v$active_session_history中檢視持有鎖會話的相關資訊，發現這些會話一直處於等待狀態，等待事件一直是transaction。

關於transaction等待事件：等待其它事務rollback，這些事務可能是異常中斷或者手工rollback，因為一些鎖沒有釋放，阻塞了其它會話

[@more@]

從以上可知，公司資料庫中曾發生大的事務被rollback的情況，一些事務等待rollback完成導致語句執行效率低從而阻塞了其它會話。

事實上，從資料庫警告日誌中發現了這些資訊：
Thu Jan 28 11:27:27 2010
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
Transaction recovery: lock conflict caught and ignored
從smon和pmon的trace檔案中，發現了下面的資訊：
*** 2010-01-28 11:21:51.510
[claim lock for dead process][lp 0x700000d67c709a8][p 0x700000d61eec7b0.532690][hist x977d4951]
*** 2010-01-28 11:37:05.406
[claim lock for dead process][lp 0x700000d5a3cf9c8][p 0x700000d61f2a970.1020760][hist x49514951]

*** 2010-01-28 12:25:06.546
Serial Transaction recovery caught exception 30319
*** 2010-01-28 12:29:06.763
Serial Transaction recovery caught exception 30319
*** 2010-01-28 12:33:08.776
Serial Transaction recovery caught exception 30319
*** 2010-01-28 12:37:08.967
Serial Transaction recovery caught exception 30319
這些進一步證實了上面的結論，事實上，[claim lock for dead process][lp 0x700000d67c709a8][p 0x700000d61eec7b0.532690]也說明未完成rollback的程式ID為：532690