觸發寫Redo Log的條件

參見；http://www.ixora.com.au/notes/redo_write_triggers.htm http://www.eygle.com/archives/2005/02/redoaeoeio.html There are four conditions that cause LGWR to perform a redo write. When LGWR is idle, it sleeps on an rdbms ipc message wait with a timeout of 3 seconds (as does DBWn). If this sleep times out and LGWR finds that there is some redo available to write, a background write is performed spontaneously. Whenever a process allocates space in the log buffer, the number of used log buffer blocks is calculated. If the number of used blocks is greater than or equal to the number of blocks specified by the _log_io_size parameter, and if LGWR is not already active, then LGWR is posted to perform a background write. The default value for _log_io_size is 1/3 of the log buffer expressed in log blocks, with an upper bound equivalent to 1 Mb from release 8.0. As with many other hidden parameters, unless set explicitly, the _log_io_size parameter reports as zero in X$KSPPSV. When a transaction commits, it generates a commit marker in the redo stream. However, the transaction is not recoverable until the log block containing that commit marker has been flushed to disk. So, before the process finishing the transaction can return a response to the user, it must wait for LGWR to flush that log block to disk. The process therefore posts LGWR and then sleeps on a log file sync wait with a timeout of 1 second. For completeness, the _wait_for_sync parameter can be set to FALSE to avoid waiting for redo to be synced, but doing so voids any guarantee of recoverability for committed transactions upon instance failure. Note that commits within recursive calls (such as procedural code execute calls) do not need to sync their redo until a response is about to be returned to the user. Therefore recursive calls just sync the commit RBA of their most recent COMMIT upon return to the user call. They do not sync each commit. An SGA variable (kcrfshsb, according to bug 182447) is used to communicate the log block number up to which the redo thread needs to be synced. If several commits occur in distinct transactions before LGWR wakes up, this variable records the highest log block number that needs to be synced, and the commit markers are all flushed to disk in a single redo write. This is sometimes called a group commit. When DBWn needs to write one or more blocks for which the high RBA is beyond LGWR's on-disk RBA, from Oracle 8i, it places those blocks into its deferred write queue and posts LGWR to sync the highest high RBA, but it does not wait. Instead DBWn continues to process other writes that do not need to be deferred. Prior to release 8i, DBWn used to sleep on a log file sync wait in this case. 爲了保證用戶能夠快速提交，LGWR的寫出必須很是活躍，咱們很是熟悉的LGWR寫觸發條件就有4條。

1. 每3秒超時（Timeout）

當LGWR處於空閒狀態時，它依賴於rdbms ipc message等待，處於休眠狀態，直到3秒超時時間到。若是LGWR發現有redo須要寫出，那麼LGWR將執行寫出操做，log file parallel write等待事件將會出現。

2. 閥值達到

咱們在各類文檔上常常會看到的2個觸發日誌寫的條件是： ·Redo Log Buffer 1/3滿； ·Redo Log Bufrer 具備1MB髒數據。 這兩個都是限制條件，在觸發時是協同生效的。咱們知道，只要有進程（Process）在Log Buffer中分配和使用空間，已經使用的Log Buffer的數量將被計算。若是使用的塊的數量大於或等於一個隱含參數_log_io_size的設置，那麼將會觸發LGWR寫操做。 若是此時LGWR未處於活動狀態，那麼LGWR將被通知去執行後臺寫操做。 缺省的_log_io_size等於1/3 Log Buffer大小，上限值爲1MB，此參數在X$KSPPSV（[K]ernel [S]ervice [P]arameter Component [S]ystem [V]alues）中顯示的0值，意爲缺省值。 也就是，LGWR將在Min(1M,1/3 log buffer size)時觸發。注意此處的Log Buffer Size是以Log Block來衡量的。此值一般爲512 bytes GetHidPar.sql select x.ksppinm name, y.ksppstvl value, y.ksppstdf isdefault, decode(bitand(y.ksppstvf,7),1,'MODIFIED',4,'SYSTEM_MOD','FALSE') ismod, decode(bitand(y.ksppstvf,2),2,'TRUE','FALSE') isadj from sys.x$ksppi x, sys.x$ksppcv y where x.inst_id = userenv('Instance') and y.inst_id = userenv('Instance') and x.indx = y.indx and x.ksppinm like '%_&par%' order by translate(x.ksppinm, ' _', ' ') sys@NEI> @GetHidPar Enter value for par: log_io_size old 4: AND x.ksppinm LIKE '%&par%' new 4: AND x.ksppinm LIKE '%log_io_size%' NAME VALUE DESCRIB ------------------------------ -------------------- ------------------------------------------------------------ _log_io_size 0 automatically initiate log write if this many redo blocks in buffer 一個常見的經驗推薦是將Log Buffer設置爲3MB大小，就是由於當Redo Log Buffer爲3MB時，以上兩個條件可能同時達到，從而能夠在某種程度上避免LGWR的過分激活。

3. 用戶提交 當一個事務提交時，

在Redo Stream中將記錄一個提交標誌。在這些Redo被寫到磁盤上以前，這個事務是不可恢復的。因此，在事務返回成功標誌給用戶前，必須等待LGWR寫完成。進程通知LGWR寫，而且以Log File Sync事件開始休眠，超時時間而1秒。 Oracle的隱含參數_wait_for_sync參數能夠設置爲False以免Redo File Sync的等待，可是就將沒法保證事務的恢復性。 sys@NEI> @GetHidPar Enter value for par: wait_for_sync old 4: AND x.ksppinm LIKE '%&par%' new 4: AND x.ksppinm LIKE '%wait_for_sync%' NAME VALUE DESCRIB ------------------------------ -------------------- ------------------------------------------------------------ _wait_for_sync TRUE wait for sync on commit MUST BE ALWAYS TRUE 注意：在遞歸調用（RecurSive Calls）中的提交（好比過程當中的提交）不須要同步Redo直到須要返回響應給用戶。所以遞歸調用僅須要同步返回給用戶調用以前的最後一次Commit操做的RBA。 存在一個SGA變量用以記錄Redo線程須要同步的Log Block Number。若是多個提交在喚醒LGWR以前發生，此變量記錄最高的Log Block Number，在此以前的全部Redo都將被寫入磁盤。這有時候稱爲組提交（Group Commit）。

4. 在DBWn寫以前

若是DBWR將要寫出的數據的High RBA超過LGWR的On-Disk RBA，DBWR將通知LGWR去執行寫出（不然這部分數據在Recovery時將沒法恢復）。在Oracle 8i以前，此時DBWR將等待log file sync事件；從Oracle 8i開始，DBWR把這些Block放入一個延遲隊列，同時通知LGWR執行Redo寫出，DBWR能夠繼續執行無需等待的數據寫出。 --------------------- 本文來自 babymouse1212 的CSDN 博客 ，全文地址請點擊：https://blog.csdn.net/babymouse1212/article/details/71078560?utm_source=copy