Smon:parallel Transaction Recovery tried issue--reprint

smon:parallel Transaction Recovery tried this is usually caused by killing a process while running a large amount of data transaction and causing Smon to clean up the rollback segment.

This is when the business peak time, if found this, may cause Smon to occupy the 100% CPU and cause the system hang over there.
Even if you shutdown immediate, Oracle will wait for Smon cleanup to shut down, and this waiting process may be lengthy.
If you shutdown abort, then Oracle will shutdown immediately, but when you start, it can be slow, because Smon will then clean up the undo, which may be a long wait:
— — — ——————————————————————————————————
Completed:alter DATABASE MOUNT
Thu 26 22:43:57 2010
ALTER DATABASE OPEN
Thu 26 22:43:57 2010
Beginning crash Recovery of 1 threads
Thu 26 22:43:57 2010
Started First Pass Scan
Thu 26 22:43:57 2010
Completed first pass scan
402218 redo blocks read, 126103 data blocks need recovery
Thu 26 22:45:05 2010
Restarting dead background process QMN0
QMN0 started with pid=16
Thu 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 26 22:45:21 2010
Completed Redo Application
Thu 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
________________________________________________
Look at the red labeled one, waited 3 minutes to finish recovery.
So how can we make it fast, Metalink (238507.1There are some ways to do this:
---------------------------------------------------------------------------------------------
1. Find Smon ' s Oracle PID:
Example:
Sql> Select PID, program from v$process where program like '%smon% ';
PID Program
---------- ------------------------------------------------
6 [email protected] (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 is doing parallel transaction recovery.
You can check the 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, the This command might hang, if it does just control-c out of it. Need to try the 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
——————————————————————————————————
The above idea is mainly to change the function of Smon parallel recovery to non-parallel, the main
Fast_start_parallel_rollback is the function of this parameter.
There is cases where parallel transaction recovery was not as fast as serial transaction recovery, because the PQ slaves a Re interfering with all other. This depends mainly in the type of changes that need to be made during rollback and usually if happen when rolling back INDEX Updates in parallel.

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

Smon:parallel Transaction Recovery tried issue--reprint