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

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/85922/viewspace-1030978/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/85922/viewspace-1030978/