關(guān)于Oracle實例恢復(fù)的前滾和回滾的理解
關(guān)于oracle實例恢復(fù)的一些理解,一直都有誤區(qū),今天通過查看相關(guān)資料和與同學(xué)探討,發(fā)覺了自己的錯誤,探討結(jié)果如下:
實例恢復(fù):當(dāng)數(shù)據(jù)庫非正常關(guān)閉的時候(斷電或者shu abort等等非一致性關(guān)閉),當(dāng)你從新啟動數(shù)據(jù)庫的時候,數(shù)據(jù)庫相關(guān)進(jìn)程自動進(jìn)行實例恢復(fù),無須人工干預(yù)。
什么時候需要實例恢復(fù)
在shutdown normal or shutdown immediate下,也就是所謂的clean shutdown,checkpoint也會自動觸發(fā),并且把SCN紀(jì)錄寫回。 當(dāng)發(fā)生checkpoint時,會把SCN寫到四個地方:
三個地方于control file內(nèi):
- SYSTEM CHECKPOINT SCN
- Datafile checkpoint SCN
- Stop SCN:就是在實例一致性關(guān)閉的時候,更新
一個在datafile header內(nèi):
1.Start SCN
正常open的狀態(tài)下一致性的數(shù)據(jù)庫,SYSTEM CHECKPOINT SCN,Datafile checkpoint SCN和數(shù)據(jù)文件頭Start SCN的這三個SCN是一致,并且儲存在control file中的stop scn就會恢復(fù)為NULL值。
Clean shutdown 時
當(dāng)clean shutdown 時,checkpoint會進(jìn)行,并且此時datafile的stop scn和控制文件里的start scn會相同, 等到open數(shù)據(jù)庫時,Oracle檢查datafile header中的start scn和存于control file中的datafile的scn是否相同, 如果相同,接著檢查start scn和stop scn是否相同,如果仍然相同,數(shù)據(jù)庫就會正常開啟,否則就需要recovery。
等到數(shù)據(jù)庫開啟后,儲存在control file中的stop scn就會恢復(fù)為NULL值,此時表示datafile是open在正常模式下了。
非正常shutdown
如果不正常SHUTDOWN (shutdown abort),則mount數(shù)據(jù)庫后,會發(fā)現(xiàn)stop scn并不是等于其它位置的scn, 而是等于NULL,這表示Oracle在shutdown時沒有進(jìn)行checkpoint,下次開機(jī)必須進(jìn)行crash recovery(實例恢復(fù))。
注意一點:
- 啟動數(shù)據(jù)庫時,如果發(fā)現(xiàn)STOP SCN = NULL,表示需要進(jìn)行crash recovery;
- 啟動數(shù)據(jù)庫時,如果發(fā)現(xiàn)有datafile header的START SCN 不等于儲存于CONTROLFILE的DATAFILE SCN,表示需要進(jìn)行Media recovery
2.實例恢復(fù)的具體過程
當(dāng)數(shù)據(jù)庫突然崩潰,而還沒有來得及將buffer cache里的臟數(shù)據(jù)塊刷新到數(shù)據(jù)文件里,同時在實例崩潰時正在運行著的事務(wù)被突然中斷,則事務(wù)為中間狀態(tài),也就是既沒有提交也沒有回滾。這時數(shù)據(jù)文件里的內(nèi)容不能體現(xiàn)實例崩潰時的狀態(tài)。這樣關(guān)閉的數(shù)據(jù)庫是不一致的。
下次啟動實例時,Oracle會由SMON進(jìn)程自動進(jìn)行實例恢復(fù)。實例啟動時,SMON進(jìn)程會去檢查控制文件中所記錄的、每個在線的、可讀寫的數(shù)據(jù)文件的END SCN號。
數(shù)據(jù)庫正常運行過程中,該END SCN號始終為NULL,而當(dāng)數(shù)據(jù)庫正常關(guān)閉時,會進(jìn)行完全檢查點,并將檢查點SCN號更新該字段,所以可以通過END SCN號是否為null來判斷是不是需要實例恢復(fù)。
而崩潰時,Oracle還來不及更新該字段,則該字段仍然為NULL。當(dāng)SMON進(jìn)程發(fā)現(xiàn)該字段為空時,就知道實例在上次沒有正常關(guān)閉,于是由SMON進(jìn)程就開始進(jìn)行實例恢復(fù)了。
SMON進(jìn)程進(jìn)行實例恢復(fù)時,會從控制文件中獲得檢查點位置。于是,SMON進(jìn)程到聯(lián)機(jī)日志文件中,找到該檢查點位置,然后從該檢查點位置開始往下,應(yīng)用所有的重做條目,從而在buffer cache里又恢復(fù)了實例崩潰那個時間點的狀態(tài)。這個過程叫做前滾,前滾完畢以后,buffer cache里既有崩潰時已經(jīng)提交還沒有寫入數(shù)據(jù)文件的臟數(shù)據(jù)塊,也還有事務(wù)被突然終止,而導(dǎo)致的既沒有提交又沒有回滾的事務(wù)所弄臟的數(shù)據(jù)塊。
前滾一旦完畢,SMON進(jìn)程立即打開數(shù)據(jù)庫。但是,這時的數(shù)據(jù)庫中還含有那些中間狀態(tài)的、既沒有提交又沒有回滾的臟塊,這種臟塊是不能存在于數(shù)據(jù)庫中的,因為它們并沒有被提交,必須被回滾。打開數(shù)據(jù)庫以后,SMON進(jìn)程會在后臺進(jìn)行回滾。
有時,數(shù)據(jù)庫打開以后,SMON進(jìn)程還沒來得及回滾這些中間狀態(tài)的數(shù)據(jù)塊時,就有用戶進(jìn)程發(fā)出讀取這些數(shù)據(jù)塊的請求。這時,服務(wù)器進(jìn)程在將這些塊返回給用戶之前,由服務(wù)器進(jìn)程負(fù)責(zé)進(jìn)行回滾,回滾完畢后,將數(shù)據(jù)塊的內(nèi)容返回給用戶。
3.為什么數(shù)據(jù)庫的實例恢復(fù)是先前滾再回滾
回滾段實際上也是以回滾表空間的形式存在的,既然是表空間,那么肯定就有對應(yīng)的數(shù)據(jù)文件,同時在buffer cache 中就會存在映像塊,這一點和其他表空間的數(shù)據(jù)文件相同。
當(dāng)發(fā)生DML操作時,既要生成REDO(針對DML操作本身的REDO Entry)也要生成UNDO(用于回滾該DML操作,記錄在UNDO表空間中),但是既然UNDO信息也是使用回滾表空間來存放的,那么該DML操作對應(yīng)的UNDO信息(在BUFFER CACHE生成對應(yīng)中的UNDO BLOCK)就會首先生成其對應(yīng)的REDO信息(UNDO BLOCK's REDO Entry)并寫入Log Buffer中。
這樣做的原因是因為Buffer Cache中的有關(guān)UNDO表空間的塊也可能因為數(shù)據(jù)庫故障而丟失,為了保障在下一次啟動時能夠順利進(jìn)行回滾,首先就必須使用REDO日志來恢復(fù)UNDO段(實際上是先回復(fù)Buffer Cache中的臟數(shù)據(jù)塊,然后由Checkpoint寫入UNDO段中),在數(shù)據(jù)庫OPEN以后再使用UNDO信息來進(jìn)行回滾,達(dá)到一致性的目的。
生成完UNDO BLOCK's REDO Entry后才輪到該DML語句對應(yīng)的REDO Entry,最后再修改Buffer Cache中的Block,該Block同時變?yōu)榕K數(shù)據(jù)塊。
實際上,簡單點說REDO的作用就是記錄所有的數(shù)據(jù)庫更改,包括UNDO表空間在內(nèi)。
總 結(jié)
今天最重要的一點我知道了,所謂的前滾,是應(yīng)用redo來恢復(fù)buffer cache的數(shù)據(jù),將buffer cache恢復(fù)到crash之前狀態(tài),所以此時buffer cache 中既有崩潰時已經(jīng)提交還沒有寫入數(shù)據(jù)文件的臟數(shù)據(jù)塊,也還有事務(wù)被突然終止,而導(dǎo)致的既沒有提交又沒有回滾的事務(wù)所弄臟的數(shù)據(jù)塊(也就是沒有commit,但是dbwr已經(jīng)將改變刷新到底層磁盤),還有一點是控制文件中還有一個 end scn,用來記錄數(shù)據(jù)庫正常關(guān)閉的時候的數(shù)據(jù)庫文件頭的scn,并且可以通過這個scn是否為null來判斷需或者不需實例恢復(fù)。




















