mttr-mean time to recover
mtbf-mean time between failures
先要明白一些概念：
日誌檔案中的資訊為了當系統出現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裡的髒資料塊重新整理到資料檔案裡，同時在例項崩潰時正在執行著的事務被突然中斷，則事務為中間狀態，也就是既沒有提交也沒有回滾。這時資料檔案裡的內容不能體現例項崩潰時的狀態。這樣關閉的資料庫是不一致的。
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就不能較快地被響應。但是例項恢復的時間會更短。
（2010 07 14）Oracle例項恢復詳解
又有一段時間沒接觸oracle了，也就是沒有天天都保證乙個小時以上的oracle學習時間，慚愧，意志力不夠。感覺oracle的學習真的是乙個比較長期的過程，在其中的學習過程中會經歷沮喪，恐懼，甚至受挫感，我想這就是我這整整一年oracle的學習體會吧。然而oracle的學習也是乙個柳暗花明的過程，在...
Oracle例項恢復
例項恢復會在資料庫沒有安全關閉的情況下會發生，在資料庫shutdown abort和資料庫異常 down 掉，或者斷電會發生例項恢復。例項恢復的原因就是，在資料庫 down 掉那一刻，有部分修改過的資料沒有寫到磁碟上面，雖然資料在記憶體裡面丟掉了，但是 redo 寫到磁碟上面了，所以例項恢復用 re...
Oracle例項恢復
oracle例項恢復原理 首先從事物說起，當執行update開啟乙個事物的時候，首先需要在buffer cache中找到可用的塊 block 更新資料，然後構造cr塊，將update之前的資料放入到undo中，同時會在log buffer內寫日誌，log buffer內資料每隔3秒通過lgwr程序將...