OracleRedoLog機(jī)制小結(jié)

Oracle 的Redo 機(jī)制DB的一個重要機(jī)制，理解這個機(jī)制對DBA來說也是非常重要，之前的Blog里也林林散散的寫了一些，前些日子看老白日

Oracle 的Redo 機(jī)制DB的一個重要機(jī)制，理解這個機(jī)制對DBA來說也是非常重要，之前的Blog里也林林散散的寫了一些，前些日子看老白日記里也有說明，所以結(jié)合老白日記里的內(nèi)容，對oracle 的整個Redo log 機(jī)制重新整理一下。

Oracle 的Online redo log 是為確保已經(jīng)提交的事務(wù)不會丟失而建立的一個機(jī)制。 因為這種健全的機(jī)制，才能讓我們在數(shù)據(jù)庫crash時，恢復(fù)數(shù)據(jù)，保證數(shù)據(jù)不丟失。

恢復(fù)分兩種：

（1） Crash recovery

（2） Media recovery

這兩種的具體說明，參考：

Oracle 實例恢復(fù)時 前滾（roll forward） 后滾（rollback） 問題

這兩種的區(qū)別是：

（1） Crash Recovery 是在啟動時DB 自動完成，而MediaRecovery 需要DBA 手工的完成。

（2） Crash Recovery 使用online redo log，Media Recovery 使用archived log 和 online redo log。

（3） Media Recovery 可能還需要從備份中Restore datafile。

當(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號更新該字段。

而崩潰時，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)容返回給用戶。

總之，Crash Recovery時，數(shù)據(jù)庫打開會占用比正常關(guān)閉更長的時間。

回滾段實際上也是以回滾表空間的形式存在的，既然是表空間，那么肯定就有對應(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)。

Crash Recovery 可以在細(xì)分成兩種：

（1） 實例恢復(fù)(InstanceRecovery)

（2） 崩潰恢復(fù)(CrashRecovery)

InstanceRecovery與CrashRecovery是存在區(qū)別的：針對單實例(singleinstance)或者RAC中所有節(jié)點全部崩潰后的恢復(fù)，我們稱之為Crash Recovery。 而對于RAC中的某一個節(jié)點失敗，存活節(jié)點(surviving instance)試圖對失敗節(jié)點線程上redo做應(yīng)用的情況，我們稱之為InstanceRecovery。

不管是Instance Recovery還是Crash Recovery，都由2個部分組成：cache recovery和transaction recovery。

根據(jù)官方文檔的介紹，Cache Recovery也叫Rolling Forward（前滾）；而Transaction Recovery也叫Rolling Back（回滾）。

REDO LOG 的數(shù)據(jù)是按照THREAD 來組織的，對于單實例系統(tǒng)來說，只有一個THREAD，對于RAC 系統(tǒng)來說，可能存在多個THREAD，每個數(shù)據(jù)庫實例擁有一組獨立的REDO LOG 文件，擁有獨立的LOG BUFFER，某個實例的變化會被獨立的記錄到一個THREAD 的REDO LOG 文件中。

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com