Oracle 例項恢復詳解

先要明白一些概念：

日誌檔案中的資訊為了當系統出現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的自動調整。

5.4.2.5 例項恢復的原理

前面我們講到過，當資料庫突然崩潰，而還沒有來得及將buffer cache裡的髒資料塊重新整理到資料檔案裡，同時在例項崩潰時正在執行著的事務被突然中斷，則事務為中間狀態，也就是既沒有提交也沒有回滾。這時資料檔案裡 的內容不能體現例項崩潰時的狀態。這樣關閉的資料庫是不一致的。

下次啟動例項時，Oracle會由SMON程式自動進行例項恢復。例項啟動時，SMON程式會去檢查控制檔案中所記錄的、每個線上的、可讀寫的資料 檔案的END SCN號。資料庫正常執行過程中，該END SCN號始終為空，而當資料庫正常關閉時，會進行完全檢查點，並將檢查點SCN號更新該欄位。而崩潰時，Oracle還來不及更新該欄位，則該欄位仍然為 空。當SMON程式發現該欄位為空時，就知道例項在上次沒有正常關閉，於是由SMON程式就開始進行例項恢復了。

SMON程式進行例項恢復時，會從控制檔案中獲得檢查點位置。於是，SMON程式到 聯機日誌檔案中，找到該檢查點位置，然後從該檢查點位置開始往下，應用所有的重做條目，從而在buffer cache裡又恢復了例項崩潰那個時間點的狀態。這個過程叫做前滾，前滾完畢以後，buffer cache裡既有崩潰時已經提交還沒有寫入資料檔案的髒資料塊，也還有事務被突然終止，而導致的既沒有提交又沒有回滾的事務所弄髒的資料塊。

前滾一旦完畢，SMON程式立即開啟資料庫。但是，這時的資料庫中還含有那些中間狀態的、既沒有提交又沒有回滾的髒塊，這種髒塊是不能存在於資料庫中的，因為它們並沒有被提交，必須被回滾。開啟資料庫以後，SMON程式會在後臺進行回滾。

有時，資料庫開啟以後，SMON程式還沒來得及回滾這些中間狀態的資料塊時，就有使用者程式發出讀取這些資料塊的請求。這時，伺服器程式在將這些塊返回給使用者之前，由伺服器程式負責進行回滾，回滾完畢後，將資料塊的內容返回給使用者。

Oracle提供了初始化引數fast_start_mttr_target讓我們指定完成例項恢復所花費的時間（該時間只包括前滾並開啟資料庫的 時間，不包括回滾的時間），該引數以秒為單位。比如我們設定該引數為30，表示如果發生例項崩潰，那麼下次重新啟動時，資料庫最多用30秒的時間完成前 滾，並開啟資料庫。在資料庫執行過程中，就會根據該時間，來估算30秒大致對應多少量的重做記錄，這實際上就決定了檢查點位置，如圖5-8所示。

圖5-8 檢查點佇列3

圖5-8中的紅色豎線就是檢查點位置。Oracle應用完檢查點位置以後所有的重做記錄所花費的時間就是 fast_start_mttr_target所指定的時間。也就是說，檢查點位置以後的重做記錄所對應的髒塊會被留在檢查點佇列上，而不被DBWn寫入 資料檔案。因此，該引數越大，說明要應用的重做記錄就越多，那麼留在檢查點佇列上的髒塊就越多，也就說明DBWn寫髒塊越不頻繁，佔用I/O越少，那麼前 臺使用者查詢語句的I/O就能夠越快地被響應。但是例項恢復的時間也會越長。反之，該引數越小，說明要應用的重做記錄就越少，那麼留在檢查點佇列上的髒塊就 越少，也就說明DBWn寫髒塊越頻繁，因而佔用I/O越多，那麼前臺使用者查詢語句的I/O就不能較快地被響應。但是例項恢復的時間會更短。