Redo的原理

我們知道，使用者資料通常在Buffer Cache中修改，Oracle通過快取記憶體來提高資料操作的效能。當使用者在Buffer Cache中修改資料時，Oracle並不會立即將變更資料寫出到資料檔案上，因為獨立的離散寫出效率會很低。到目前為止，計算機系統中最容易出現瓶頸的仍然是磁碟的I/O操作，Oracle這樣做的目的是為了減少IO的壓力，當修改過的資料達到一定數量之後，可以進行高效地批量寫出。

大部分傳統資料庫（當然包括Oracle）在處理資料修改時都遵循no-force-at-commit策略。也就是說，在提交時並不強制寫。那麼為了保證資料在資料庫發生故障時（例如：斷電）可以恢復，Oracle引入了Redo機制，通過連續的、順序的日誌條目的寫出將隨機的、分散的資料塊的寫出推延。這個推延使得資料的寫出可以獲得批量效應等效能提升。

同Redo Log Buffer類似，Redo Log File也是迴圈使用的，Oracle允許使用最少兩個日誌組。預設的，資料庫建立時會建立3個日誌組。

sys@NEI> select group#,members,status from v$log;
    GROUP#    MEMBERS STATUS
---------- ---------- ----------------
         1          1 INACTIVE
         2          1 CURRENT
         3          1 INACTIVE

當一個日誌檔案寫滿之後，會切換到另外一個日誌檔案，這個切換過程稱為Log Switch。Log Switch會觸發一個檢查點，促使DBWR程式將寫滿的日誌檔案保護的變更資料寫回資料庫。在檢查點完成之前，日誌檔案是不能被重用的。

由於Redo機制對於資料的保護，當資料庫發生故障時，Oracle就可以通過Redo重演進行資料恢復。那麼一個非常重要的問題是，恢復應該從何開始呢？如果讀取的Redo過多，那麼必然導致恢復的時間過長，在生產環境中，我們必須保證恢復時間儘量的短。

Oracle通過檢查點（Checkpoint）來縮減恢復時間。檢查點只是一個資料庫事件，它存在的根本意義在於減少恢復時間。

當檢查點發生時（此時的SCN被稱為Checkpoint SCN）Oracle會通知DBWR程式，把修改過的資料，也就是此Checkpoint SCN之前的髒資料（Dirty Duffer）從Buffer Cache寫入磁碟，在檢查點完成後CKPT程式會相應地更新控制檔案和資料檔案頭，記錄檢查點資訊，標識變更。

在檢查點完成之後，此檢查點之前修改過的資料都已經寫回磁碟，重做日誌檔案中的相應重做記錄對於崩潰/例項恢復不再有用。如果此後資料庫崩潰，那麼恢復只需要從最後一次完成的檢查點開始恢復即可。如果資料庫執行在歸檔模式（所有生產資料庫，都建議執行在歸檔模式），日誌檔案在重用之前必須寫出到歸檔日誌檔案，歸檔日誌在介質恢復時可以用來恢復資料庫故障。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8183550/viewspace-659582/，如需轉載，請註明出處，否則將追究法律責任。