SMON: Parallel transaction recovery tried 引起的問題--轉載

 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 ） 有給出一些作法：
---------------------------------------------------------------------------------------------
1. Find SMON's Oracle PID:
Example:
SQL> select pid, program from v$process where program like '%SMON%';
       PID PROGRAM
---------- ------------------------------------------------
         6 oracle@stsun7 (SMON) 
2. Disable SMON transaction cleanup:
SVRMGR> oradebug setorapid <SMON's Oracle PID>
SVRMGR> oradebug event 10513 trace name context forever, level 2 
3. Kill the PQ slaves that are doing parallel transaction recovery. 
You can check V$FAST_START_SERVERS to find these.
4. Turn off fast_start_parallel_rollback:
alter system set fast_start_parallel_rollback=false; 
If SMON is recovering, this command might hang, if it does just control-C out of it.  You may need to try this many times to get this to complete (between SMON cycles).
5. Re-enable SMON txn recovery:
SVRMGR> oradebug setorapid <SMON's Oracle PID>
SVRMGR> oradebug event 10513 trace name context off 
——————————————————————————————————
以上的思路主要是要把 SMON 並行 recovery 的功能給改爲非並行，主要
是 fast_start_parallel_rollback 這個參數的做用。
There are cases where parallel transaction recovery is not as fast as serial transaction recovery, because the pq slaves are interfering with each other. This depends mainly on the  type of changes that need to be made during rollback and usually may happen when rolling back INDEX Updates in parallel. 

http://czmmiao.iteye.com/blog/1334948