MTTR-Mean Time To Recover
MTBF-Mean Time Between Failures
先要明白一些概念:
日志文件中的信息為了當(dāng)系統(tǒng)出現(xiàn)failure時(shí),保證事務(wù)可以恢復(fù)。當(dāng)用戶事務(wù)完成發(fā)出commit時(shí),總是先等待LGWR進(jìn)程將事務(wù)所需的redo信息寫到日志文件(之前可能在redo buffer中)后,才會(huì)收到commit complete信息。
DBWR進(jìn)程總是比LGWR進(jìn)程寫的速度慢(DBWR進(jìn)程是隨機(jī)寫,LGWR進(jìn)程是順序?qū)懀S機(jī)寫比順序?qū)懸?/p>
當(dāng)DBWR進(jìn)程要將緩存區(qū)中的信息寫入到數(shù)據(jù)文件時(shí),會(huì)先通知LGWR進(jìn)程將事務(wù)相關(guān)的redo信息寫入到日志文件。
SCN可以理解為一個(gè)標(biāo)簽,ORACLE對(duì)數(shù)據(jù)庫中的每個(gè)操作都打上一個(gè)標(biāo)簽。這個(gè)標(biāo)簽是順序增加的。永遠(yuǎn)不會(huì)歸0(除非數(shù)據(jù)庫重建)
CHECKPOINT是ORACLE為了記錄哪些數(shù)據(jù)已經(jīng)被寫入到數(shù)據(jù)文件中。
CHECKPOINT的作用就是要保證當(dāng)checkpoint發(fā)生時(shí),這個(gè)checkpoint SCN之前的數(shù)據(jù)都要由DBWR寫入到數(shù)據(jù)文件中,而在DBWR寫之前,又會(huì)觸發(fā)LGWR進(jìn)程將相關(guān)的redo信息寫入到日志文件中。這樣,checkpoint完成后,發(fā)生instance failure時(shí)就不再需要恢復(fù)這個(gè)checkpoint SCN前的信息.
理解實(shí)例恢復(fù)的相關(guān)信息:
Instance Recovery所需要的信息,就是最近一次checkpoint之后到日志文件結(jié)尾的這些redo信息。
因?yàn)閏heckpoint之前的數(shù)據(jù)都已經(jīng)一致性地寫入到數(shù)據(jù)文件中了,而之后的數(shù)據(jù)可能有一部分已經(jīng)寫進(jìn)數(shù)據(jù)文件,而有一部分沒有寫進(jìn)數(shù)據(jù)文件。
Instance Recovery所需要的時(shí)間,將數(shù)據(jù)文件 從最近一次checkpoint開始,恢復(fù)到控制文件中記錄的這個(gè)數(shù)據(jù)文件的最后一個(gè)SCN值為止,應(yīng)用這兩者之間redo信息的時(shí)間就是instance recovery所要花費(fèi)的時(shí)間。
實(shí)例恢復(fù)的調(diào)整:
由上面的信息可以總結(jié)出,實(shí)例恢復(fù)最關(guān)鍵的問題的就是最近一次CHECKPOINT發(fā)生的時(shí)間,以及CHECKPOINT發(fā)生的頻率。只有確認(rèn)了最近一次CHECKPOIN發(fā)生的時(shí)間點(diǎn),才能確定恢復(fù)所需的redo信息,以及恢復(fù)所要花費(fèi)的時(shí)間。
對(duì)于instance recovery花費(fèi)時(shí)間的調(diào)優(yōu),就是對(duì)參數(shù)FAST_START_MTTR_TARGE的調(diào)整,單位“秒”,大值為3600秒。
也就是說FAST_START_MTTR_TARGET這個(gè)參數(shù)的設(shè)置會(huì)直接影響到checkpoint發(fā)生的頻率。
FAST_START_MTTR_TARGE所設(shè)置的時(shí)間就是用戶希望數(shù)據(jù)庫用在instance recovery的時(shí)間。也就是從應(yīng)用最近一次checkpoint到日志信息最后這兩個(gè)點(diǎn)之間redo信息所要花費(fèi)的時(shí)間。
MTTR設(shè)置的時(shí)間過小的話,會(huì)造成系統(tǒng)checkpoint過于頻繁,而發(fā)生checkpoint時(shí)就要DBWR,LGWR等進(jìn)程寫數(shù)據(jù)文件,產(chǎn)生物理IO,久而久之,數(shù)據(jù)庫性能會(huì)越來越慢;
MTTR設(shè)置的時(shí)間過大的話,當(dāng)實(shí)例失敗時(shí),instance recover所花費(fèi)的時(shí)間就會(huì)過長。
從10g開始,數(shù)據(jù)庫可以實(shí)現(xiàn)自動(dòng)調(diào)整,如果FAST_START_MTTR_TARGET=0時(shí),可以從alert里面看到如下信息:
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
此時(shí),數(shù)據(jù)庫會(huì)根據(jù)負(fù)載自動(dòng)調(diào)整checkpoint發(fā)生的頻率。
如果要嚴(yán)格要求instance recovery時(shí)間的話,就設(shè)置FAST_START_MTTR_TARGET參數(shù),如果不是那么嚴(yán)格的話,建議用10g的自動(dòng)調(diào)整。
5.4.2.5 實(shí)例恢復(fù)的原理
前面我們講到過,當(dāng)數(shù)據(jù)庫突然崩潰,而還沒有來得及將buffer cache里的臟數(shù)據(jù)塊刷新到數(shù)據(jù)文件里,同時(shí)在實(shí)例崩潰時(shí)正在運(yùn)行著的事務(wù)被突然中斷,則事務(wù)為中間狀態(tài),也就是既沒有提交也沒有回滾。這時(shí)數(shù)據(jù)文件里的內(nèi)容不能體現(xiàn)實(shí)例崩潰時(shí)的狀態(tài)。這樣關(guān)閉的數(shù)據(jù)庫是不一致的。
下次啟動(dòng)實(shí)例時(shí),Oracle會(huì)由SMON進(jìn)程自動(dòng)進(jìn)行實(shí)例恢復(fù)。實(shí)例啟動(dòng)時(shí),SMON進(jìn)程會(huì)去檢查控制文件中所記錄的、每個(gè)在線的、可讀寫的數(shù)據(jù)文件的END SCN號(hào)。數(shù)據(jù)庫正常運(yùn)行過程中,該END SCN號(hào)始終為空,而當(dāng)數(shù)據(jù)庫正常關(guān)閉時(shí),會(huì)進(jìn)行完全檢查點(diǎn),并將檢查點(diǎn)SCN號(hào)更新該字段。而崩潰時(shí),Oracle還來不及更新該字段,則該字段仍然為空。當(dāng)SMON進(jìn)程發(fā)現(xiàn)該字段為空時(shí),就知道實(shí)例在上次沒有正常關(guān)閉,于是由SMON進(jìn)程就開始進(jìn)行實(shí)例恢復(fù)了。
SMON進(jìn)程進(jìn)行實(shí)例恢復(fù)時(shí),會(huì)從控制文件中獲得檢查點(diǎn)位置。于是,SMON進(jìn)程到聯(lián)機(jī)日志文件中,找到該檢查點(diǎn)位置,然后從該檢查點(diǎn)位置開始往下,應(yīng)用所有的重做條目,從而在buffer cache里又恢復(fù)了實(shí)例崩潰那個(gè)時(shí)間點(diǎn)的狀態(tài)。這個(gè)過程叫做前滾,前滾完畢以后,buffer cache里既有崩潰時(shí)已經(jīng)提交還沒有寫入數(shù)據(jù)文件的臟數(shù)據(jù)塊,也還有事務(wù)被突然終止,而導(dǎo)致的既沒有提交又沒有回滾的事務(wù)所弄臟的數(shù)據(jù)塊。
前滾一旦完畢,SMON進(jìn)程立即打開數(shù)據(jù)庫。但是,這時(shí)的數(shù)據(jù)庫中還含有那些中間狀態(tài)的、既沒有提交又沒有回滾的臟塊,這種臟塊是不能存在于數(shù)據(jù)庫中的,因?yàn)樗鼈儾]有被提交,必須被回滾。打開數(shù)據(jù)庫以后,SMON進(jìn)程會(huì)在后臺(tái)進(jìn)行回滾。
有時(shí),數(shù)據(jù)庫打開以后,SMON進(jìn)程還沒來得及回滾這些中間狀態(tài)的數(shù)據(jù)塊時(shí),就有用戶進(jìn)程發(fā)出讀取這些數(shù)據(jù)塊的請(qǐng)求。這時(shí),服務(wù)器進(jìn)程在將這些塊返回給用戶之前,由服務(wù)器進(jìn)程負(fù)責(zé)進(jìn)行回滾,回滾完畢后,將數(shù)據(jù)塊的內(nèi)容返回給用戶。
Oracle提供了初始化參數(shù)fast_start_mttr_target讓我們指定完成實(shí)例恢復(fù)所花費(fèi)的時(shí)間(該時(shí)間只包括前滾并打開數(shù)據(jù)庫的時(shí)間,不包括回滾的時(shí)間),該參數(shù)以秒為單位。比如我們?cè)O(shè)置該參數(shù)為30,表示如果發(fā)生實(shí)例崩潰,那么下次重新啟動(dòng)時(shí),數(shù)據(jù)庫最多用30秒的時(shí)間完成前滾,并打開數(shù)據(jù)庫。在數(shù)據(jù)庫運(yùn)行過程中,就會(huì)根據(jù)該時(shí)間,來估算30秒大致對(duì)應(yīng)多少量的重做記錄,這實(shí)際上就決定了檢查點(diǎn)位置,如圖5-8所示。
圖5-8 檢查點(diǎn)隊(duì)列3 |
圖5-8中的紅色豎線就是檢查點(diǎn)位置。Oracle應(yīng)用完檢查點(diǎn)位置以后所有的重做記錄所花費(fèi)的時(shí)間就是 fast_start_mttr_target所指定的時(shí)間。也就是說,檢查點(diǎn)位置以后的重做記錄所對(duì)應(yīng)的臟塊會(huì)被留在檢查點(diǎn)隊(duì)列上,而不被DBWn寫入數(shù)據(jù)文件。因此,該參數(shù)越大,說明要應(yīng)用的重做記錄就越多,那么留在檢查點(diǎn)隊(duì)列上的臟塊就越多,也就說明DBWn寫臟塊越不頻繁,占用I/O越少,那么前臺(tái)用戶查詢語句的I/O就能夠越快地被響應(yīng)。但是實(shí)例恢復(fù)的時(shí)間也會(huì)越長。反之,該參數(shù)越小,說明要應(yīng)用的重做記錄就越少,那么留在檢查點(diǎn)隊(duì)列上的臟塊就越少,也就說明DBWn寫臟塊越頻繁,因而占用I/O越多,那么前臺(tái)用戶查詢語句的I/O就不能較快地被響應(yīng)。但是實(shí)例恢復(fù)的時(shí)間會(huì)更短。
本文標(biāo)題:(轉(zhuǎn))Oracle實(shí)例恢復(fù)詳解MTTR-創(chuàng)新互聯(lián)
轉(zhuǎn)載來于:http://muchs.cn/article38/hoopp.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站排名、網(wǎng)站導(dǎo)航、定制網(wǎng)站、網(wǎng)站制作、Google
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容