Oracle通過Redo來保證數(shù)據(jù)庫的事務(wù)可以被重演,從而使得在故障之后,數(shù)據(jù)可以被恢復(fù)。Redo對于Oracle數(shù)據(jù)庫來說至關(guān)重要。
在數(shù)據(jù)庫中,Redo的功能主要通過3個組件來實現(xiàn):Redo Log Buffer、LGWR后臺進程和Redo Log File(在歸檔模式下,Redo Log File最終會寫出為歸檔日志文件)。
在Oracle的SGA中,存在一塊共享內(nèi)存,稱為Redo Log Buffer,如圖6-1所示。

圖6-1 Oracle Instance
Redo Log Buffer位于SGA之中,是一塊循環(huán)使用的內(nèi)存區(qū)域,其中保存數(shù)據(jù)庫變更的相關(guān)信息。這些信息以重做條目(Redo Entries)形式存儲(Redo Entries也經(jīng)常被稱為Redo Records)。Redo Entries包含重構(gòu)、重做數(shù)據(jù)庫變更的重要信息,這些變更包括INSERT、UPDATE、DELETE、CREATE、ALTER或者DROP等。在必要的時候Redo Entries被用于數(shù)據(jù)庫恢復(fù)。
Redo Entries的內(nèi)容被Oracle數(shù)據(jù)庫進程從用戶的內(nèi)存空間復(fù)制到SGA中的Redo Log Buffer之中。Redo Entries在內(nèi)存中占用連續(xù)的順序空間,由于Redo Log Buffer是循環(huán)使用的,Oracle通過一個后臺進程LGWR不斷地把Redo Log Buffer的內(nèi)容寫出到Redo Log File中。
當(dāng)用戶在Buffer Cache中修改數(shù)據(jù)時,Oracle并不會立即將修改數(shù)據(jù)寫出到數(shù)據(jù)文件上,因為那樣做效率會很低,到目前為止,計算機系統(tǒng)中最繁忙的部分是磁盤的I/O操作,Oracle這樣做的目的是為了減少IO的次數(shù),當(dāng)修改過的數(shù)據(jù)達到一定數(shù)量之后,可以進行高效地批量寫出。
大部分傳統(tǒng)數(shù)據(jù)庫(當(dāng)然包括Oracle)在處理數(shù)據(jù)修改時都遵循no-force-at-commit策略。也就是說,在提交時并不強制寫。那么為了保證數(shù)據(jù)在數(shù)據(jù)庫發(fā)生故障時(例如斷電)可以恢復(fù),Oracle引入了Redo機制,通過連續(xù)的、順序的日志條目的寫出將隨機的、分散的數(shù)據(jù)塊的寫出推延。這個推延使得數(shù)據(jù)的寫出可以獲得批量效應(yīng)的性能提升。
同Redo Log Buffer類似,Redo Log File也是循環(huán)使用的,Oracle允許使用最少兩個日志組。缺省情況下,數(shù)據(jù)庫創(chuàng)建時會建立3個日志組。
SQL> select group#,members,status from v$log;
GROUP# MEMBERS STATUS
---------- ---------- ----------------
1 1 INACTIVE
2 1 CURRENT
3 1 INACTIVE
當(dāng)一個日志文件寫滿之后,會切換到另外一個日志文件,這個切換過程稱為Log Switch。Log Switch會觸發(fā)一個檢查點,促使DBWR進程將寫滿的日志文件保護的變更數(shù)據(jù)寫回到數(shù)據(jù)庫。在檢查點完成之前,日志文件是不能夠被重用的。
由于Redo機制對于數(shù)據(jù)的保護,當(dāng)數(shù)據(jù)庫發(fā)生故障時,Oracle就可以通過Redo重演進行數(shù)據(jù)恢復(fù)。那么一個非常重要的問題是,恢復(fù)應(yīng)該從何處開始呢?
如果讀取的Redo過多,那么必然導(dǎo)致恢復(fù)的時間過長,在生產(chǎn)環(huán)境中,我們必需保證恢復(fù)時間要盡量得短。Oracle通過檢查點(Checkpoint)來縮減恢復(fù)時間。回顧一下第1章中所提到的內(nèi)容:檢查點只是一個數(shù)據(jù)庫事件,它存在的根本意義在于減少恢復(fù)時間。
當(dāng)檢查點發(fā)生時(此時的SCN被稱為Checkpoint SCN)Oracle會通知DBWR進程,把修改過的數(shù)據(jù),也就是此Checkpoint SCN之前的臟數(shù)據(jù)(Dirty Buffer)從Buffer Cache寫入磁盤,在檢查點完成后CKPT進程會相應(yīng)地更新控制文件和數(shù)據(jù)文件頭,記錄檢查點信息,標(biāo)識變更。
在檢查點完成之后,此檢查點之前修改過的數(shù)據(jù)都已經(jīng)寫回磁盤,重做日志文件中的相應(yīng)重做記錄對于崩潰/實例恢復(fù)不再有用。如果此后數(shù)據(jù)庫崩潰,那么恢復(fù)只需要從最后一次完成的檢查點開始恢復(fù)即可。如果數(shù)據(jù)庫運行在歸檔模式(所有生產(chǎn)數(shù)據(jù)庫,都建議運行在歸檔模式),日志文件在重用之前必須寫出到歸檔日志文件,歸檔日志在介質(zhì)恢復(fù)時可以用來恢復(fù)數(shù)據(jù)庫故障。