Oracle 10g 執行個體恢複Tuning

先要明白一些概念：

記錄檔中的資訊為了當系統出現failure時，保證事務可以恢複。當使用者事務完成發出commit時，總是先等待LGWR進程將事務所需的redo資訊寫到記錄檔（之前可能在redo buffer中）後，才會收到commit complete資訊。

DBWR進程總是比LGWR進程寫的速度慢（DBWR進程是隨機寫，LGWR進程是順序寫，隨機寫比順序寫要慢）

當DBWR進程要將緩衝區中的資訊寫入到資料檔案時，會先通知LGWR進程將事務相關的redo資訊寫入到記錄檔。

SCN可以理解為一個標籤，ORACLE對資料庫中的每個操作都打上一個標籤。這個標籤是順序增加的。永遠不會歸0（除非資料庫重建）

CHECKPOINT是ORACLE為了記錄哪些資料已經被寫入到資料檔案中。

CHECKPOINT的作用就是要保證當checkpoint發生時，這個checkpoint SCN之前的資料都要由DBWR寫入到資料檔案中，而在DBWR寫之前，又會觸發LGWR進程將相關的redo資訊寫入到記錄檔中。這樣，checkpoint完成後，發生instance failure時就不再需要恢複這個checkpoint SCN前的資訊.

理解執行個體恢複的相關資訊：

Instance Recovery所需要的資訊，就是最近一次checkpoint之後到記錄檔結尾的這些redo資訊。
因為checkpoint之前的資料都已經一致性地寫入到資料檔案中了，而之後的資料可能有一部分已經寫進資料檔案，而有一部分沒有寫進資料檔案。

Instance Recovery所需要的時間，將資料檔案 從最近一次checkpoint開始，恢複到控制檔案中記錄的這個資料檔案的最後一個SCN值為止，應用這兩者之間redo資訊的時間就是instance recovery所要花費的時間。

執行個體恢複的調整：

由上面的資訊可以總結出，執行個體恢複最關鍵的問題的就是最近一次CHECKPOINT發生的時間，以及CHECKPOINT發生的頻率。只有確認了最近一次CHECKPOIN發生的時間點，才能確定恢複所需的redo資訊，以及恢複所要花費的時間。

對於instance recovery花費時間的調優，就是對參數FAST_START_MTTR_TARGE的調整，單位“秒”，最大值為3600秒。

也就是說FAST_START_MTTR_TARGET這個參數的設定會直接影響到checkpoint發生的頻率。

FAST_START_MTTR_TARGE所設定的時間就是使用者希望資料庫用在instance recovery的時間。也就是從應用最近一次checkpoint到日誌資訊最後這兩個點之間redo資訊所要花費的時間。

MTTR設定的時間過小的話，會造成系統checkpoint過於頻繁，而發生checkpoint時就要DBWR，LGWR等進程寫資料檔案，產生物理IO，久而久之，資料庫效能會越來越慢；
MTTR設定的時間過大的話，當執行個體失敗時，instance recover所花費的時間就會過長。

從10g開始，資料庫可以實現自動調整，如果FAST_START_MTTR_TARGET=0時，可以從alert裡面看到如下資訊：
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
此時，資料庫會根據負載自動調整checkpoint發生的頻率。

如果要嚴格要求instance recovery時間的話，就設定FAST_START_MTTR_TARGET參數，如果不是那麼嚴格的話，建議用10g的自動調整。