MTTR-Mean Time To Recover
MTBF-Mean Time Between Failures
 

成都創新互聯主營奉新網站建設的網絡公司,主營網站建設方案,app軟件開發公司,奉新h5成都小程序開發搭建,奉新網站營銷推廣歡迎奉新等地區企業咨詢

先要明白一些概念：

日志文件中的信息為了當系統出現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就不能較快地被響應。但是實例恢復的時間會更短。

本文標題：（轉）Oracle實例恢復詳解MTTR-創新互聯
轉載來于：http://vcdvsql.cn/article38/hoopp.html

成都網站建設公司_創新互聯，為您提供營銷型網站建設、網站排名、網站導航、定制網站、網站制作、Google

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯