SMON: Parallel transaction recovery tried 这个一般是在 具有在跑大数据量的 transaction的时候 kill 掉了进程而导致 smon 去清理 回滚段时导致的。
这个在 业务高峰期的时候,如果发现这个,有可能导致 SMON 占用了 100% cpu 而导致 系统 hang 在那边。
即使你 shutdown immediate ,oracle 也会等待 smon 清理完毕才能关机,而这个等待过程也许是漫长的。
如果你 shutdown abort,那么oracle 会麻烦 shutdown ,但是,当你 startup的时候,有可能就会很慢,因为 smon 会接着清理 undo,这个等待过程也许是很漫长的:
——————————————————————————————————
Completed: ALTER DATABASE MOUNT
Thu Aug 26 22:43:57 2010
ALTER DATABASE OPEN
Thu Aug 26 22:43:57 2010
Beginning crash recovery of 1 threads
Thu Aug 26 22:43:57 2010
Started first pass scan
Thu Aug 26 22:43:57 2010
Completed first pass scan
402218 redo blocks read, 126103 data blocks need recovery
Thu Aug 26 22:45:05 2010
Restarting dead background process QMN0
QMN0 started with pid=16
Thu Aug 26 22:45:19 2010
Started recovery at
Thread 1: logseq 13392, block 381202, scn 0.0
Recovery of Online Redo Log: Thread 1 Group 3 Seq 13392 Reading mem 0
Mem# 0 errs 0: /zxindata/oracle/redolog/redo03.dbf
Recovery of Online Redo Log: Thread 1 Group 1 Seq 13393 Reading mem 0
Mem# 0 errs 0: /zxindata/oracle/redolog/redo01.dbf
Thu Aug 26 22:45:21 2010
Completed redo application
Thu Aug 26 22:48:35 2010
Ended recovery at
Thread 1: logseq 13393, block 271434, scn 2623.1377219707
126103 data blocks read, 115641 data blocks written, 402218 redo blocks read
Crash recovery completed successfully
________________________________________________
看 红色标注的那个,等待了 3 分钟才做完 recovery。
那如何才能让它快呢,metalink(238507.1) 有给出一些做法:
---------------------------------------------------------------------------------------------
我们也可以通过
另外:也许 SMON: Parallel transaction recovery tried 这个会伴
随着 SMON: Restarting fast_start parallel rollback 一起出现(曾经在 接口机上看到 10.2.0.4)
相关网址:
metalink
http://blog.chinaunix.net/u/1110/showart_1672525.html
http://hi.baidu.com/edeed/blog/item/c28f0a4610130d006b63e53f.html
http://space.itpub.net/?uid-160455-action-viewspace-itemid-617954
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/14730395/viewspace-671971/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/14730395/viewspace-671971/