深刻淺出Oracle：Redo的做用

深刻淺出Oracle：Redo的做用

Oracle經過Redo來保證數據庫的事務能夠被重演，從而使得在故障以後，數據能夠被恢復。Redo對於Oracle數據庫來講相當重要。

    在數據庫中，Redo的功能主要經過3個組件來實現：Redo Log Buffer、LGWR後臺進程和Redo Log File（在歸檔模式下，Redo Log File最終會寫出爲歸檔日誌文件）。

    在Oracle的SGA中，存在一塊共享內存，稱爲Redo Log Buffer，如圖6-1所示。

圖6-1  Oracle Instance

    Redo Log Buffer位於SGA之中，是一塊循環使用的內存區域，其中保存數據庫變動的相關信息。這些信息以重作條目（Redo Entries）形式存儲（Redo Entries也常常被稱爲Redo Records）。Redo Entries包含重構、重作數據庫變動的重要信息，這些變動包括INSERT、UPDATE、DELETE、CREATE、ALTER或者DROP等。在必要的時候Redo Entries被用於數據庫恢復。

    Redo Entries的內容被Oracle數據庫進程從用戶的內存空間複製到SGA中的Redo Log Buffer之中。Redo Entries在內存中佔用連續的順序空間，因爲Redo Log Buffer是循環使用的，Oracle經過一個後臺進程LGWR不斷地把Redo Log Buffer的內容寫出到Redo Log File中。     

    當用戶在Buffer Cache中修改數據時，Oracle並不會當即將修改數據寫出到數據文件上,由於那樣作效率會很低，到目前爲止，計算機系統中最繁忙的部分是磁盤的I/O操做，Oracle這樣作的目的是爲了減小IO的次數，當修改過的數據達到必定數量以後，能夠進行高效地批量寫出。

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

    同Redo Log Buffer相似，Redo Log File也是循環使用的，Oracle容許使用最少兩個日誌組。缺省狀況下，數據庫建立時會創建3個日誌組。

    SQL> 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）來縮減恢復時間。回顧一下第1章中所提到的內容：檢查點只是一個數據庫事件，它存在的根本意義在於減小恢復時間。

    當檢查點發生時（此時的SCN被稱爲Checkpoint SCN）Oracle會通知DBWR進程，把修改過的數據，也就是此Checkpoint SCN以前的髒數據（Dirty Buffer）從Buffer Cache寫入磁盤，在檢查點完成後CKPT進程會相應地更新控制文件和數據文件頭，記錄檢查點信息，標識變動。

    在檢查點完成以後，此檢查點以前修改過的數據都已經寫回磁盤，重作日誌文件中的相應重作記錄對於崩潰/實例恢復再也不有用。若是此後數據庫崩潰，那麼恢復只須要從最後一次完成的檢查點開始恢復便可。若是數據庫運行在歸檔模式（全部生產數據庫，都建議運行在歸檔模式），日誌文件在重用以前必須寫出到歸檔日誌文件，歸檔日誌在介質恢復時能夠用來恢復數據庫故障。