wait for stopper event to be increased

環境
OS：SunOS hostname 5.10 Generic_127111-11 sun4u sparc SUNW,Sun-Fire-V490
DB: Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

一個JOB做MVIEW refresh做了十多個小時，還沒做完，這個JOB定義：每隔20分鐘去涮新一次，發現現在JOB狀態為broken了，顯然上次refresh完全在20分鐘內完成；先查一下alert，發現日誌切換太頻繁了，2到3分鐘就切換一下，online redo才50M(也不知道那個傢伙這麼設定的),這個顯示太小了，把它擴充套件到500M,效能並沒有什麼好轉.

[@more@]

查下JOB的具體名為內容：
dbms_refresh.refresh('"SCHEM_NAME"."REFGRP"');
再根據refresh group查一下dba_refresh_children,返回441個物件，這樣的話一次refresh涮新441個物件，如果每個物件更新的資料量多，而中途中斷，這個事務是會非常大的，回滾將會是很耗時間的。
檢視一下等待事件，發現大量的：“wait for a undo record”和"free buffer waits"：
根據free buffer waits去看一下操作物件都是undo段。查一下v$session_longops，還沒完成的事務OPNAME為transaction rollback segment,而對應的session正在跑那個JOB，這個很可能是refresh出現異常，致使整個事務回滾。
根據“wait for a undo record”,發現UNDO表空間已經擴搌到30GB.
這個JOB不是第一次跑，按以往的規律來看，正常情況下是能完成refresh的.會不會被什麼阻塞了，查下發現，竟然SMON還能被正在跑的那個JOB阻塞了，查一下SMON當前等待事件，是“wait for stopper event to be increased”，這個事件比較陌生，以前根本就沒有遇到過。 奇怪的是：竟然SMON還能被job阻塞？根據這事件查一下metalink,發出一篇很相關的文件：464246.1

Sometimes Parallel Rollback of Large Transaction may become very slow. After killing a large running transaction (either by killing the shadow process or aborting the database) then database seems to hang, or smon and parallel query servers taking all the available cpu.

In fast-start parallel rollback, the background process Smon acts as a coordinator and rolls back a set of transactions in parallel using multiple server processes. Fast start parallel rollback is mainly useful when a system has transactions that run a long time before comitting, especially parallel Inserts, Updates, Deletes operations. When Smon discovers that the amount of recovery work is above a certain threshold, it automatically begins parallel rollback by dispersing the work among several parallel processes.

There are cases where parallel transaction recovery is not as fast as serial transaction recovery, because the pq slaves are interfering with each other. It looks like the changes made by this transaction cannot be recovered in parallel without causing a performance problem. The parallel rollback slave processes are most likely contending for the same resource, which results in even worse rollback performance compared to a serial rollback.

解決的辦法是：fast_start_parallel_rollback = false，該引數預設的是：LOW。

在不重新啟動資料庫的情況下：發出"alter system set fast_start_parallel_rollback = false scope=memory"後，所有的session都"enq: PE - contention".等了很長的時間，未能修改成功，只能重新啟動資料庫，同時把這個引數設定成false。

從整個事件來看，是由於一個大的事務回滾，回滾量相當大，當達到一個閥值，SMON就會用併發程式來處理，但文件上沒提到這個閥值是多少。整個事件，參與的人比較多，對資料的操作肯定比較亂，我推斷:MVIEW refresh做了很長的時間，業務人員很有可能中途強行中斷，然後重新涮新，那之前的refresh得回滾，但這個恢復工作量是比較大的，導致併發程式來恢復，而這些程式由於互相干擾，結果整個恢復比單程式恢復還慢!