Oracle例項恢復——說說前滾和回滾

 

保持資料一致性和完整性，是每一款成功商業資料庫軟體都必須要做到的基本要求。從故障中恢復，保證ACID原則，保證事務完整性，一直是Oracle資料庫核心功能組成部分。本篇主要介紹Oracle例項意外終止（斷電或者強制關閉）之後，重新啟動時發生的恢復過程，也可以稱作“前滾和回滾”。

 

基礎知識說明

 

為了更明確的說明問題，筆者首先介紹一下本文涉及到的一些重要知識。

 

資料庫例項失敗

 

我們經常說的資料庫伺服器failure是有多層含義的。Oracle資料庫是一個由多程式元件共同構成的結構體系。最重要的部分包括監聽器、Oracle資料庫例項兩個部分，當然還包括各類檔案，更廣義的還有硬體和作業系統OS。不同部分的Failure現象和處理方法都有所不同。本文所闡述的過程是Oracle例項失敗後的自動恢復過程。

 

在例項失敗的時候，往往是突然性的終止。此時Oracle資料庫可能在進行一系列完成或者未完成的事務。例項失敗恢復，就是要將這些狀態進行還原，恢復到資料完整性的狀態。

 

 

寫日誌（Redo Log）在先機制

 

Oracle資料庫是採用“日誌在先”機制的。當我們對資料庫資料進行修改時，並不是立即將修改寫入到檔案中，而是寫入到共享記憶體SGA空間中的Buffer Cache裡。同時，將修改的日誌不斷的寫入到SGA中另一塊Log Buffer快取中。有一個後臺程式LGWn不斷的將Log Buffer快取中的日誌內容寫入到online redo log檔案中。

 

 

寫入Log Buffer快取和LGWn寫入檔案的過程是非同步進行的。觸發LGWn工作的時點有幾個：

 

ü        使用者進行直接的commit操作；

ü        日誌進行切換；

ü        距離上次LGWn寫入操作超過三秒；

ü        Redo Buffer資料超過1/3或者超過1M大小；

ü        DBWn啟動，將Buffer Cache中的髒資料寫入到檔案中；

 

而資料檔案寫入程式DBWn工作的觸發點，則比較平緩和低頻率。

 

ü        當Buffer Cache中缺少用於寫入資料的clean block的時候，DBWn會開始將一些髒塊“Dirty Block”寫入到檔案中，清理出一些可以使用的Clean Block；

ü        週期性的CheckPoint寫入，當CKPT程式進行檢查點打入的時候，DBWn會啟動進行寫入；

 

綜合DBWn和LGWn工作的特點，我們可以得到日誌檔案的幾個特點：

 

首先，日誌檔案的寫入是很頻繁的。LGWn會不斷將日誌資訊從Log Buffer中寫入Online Redo Log；

 

其次，在日誌檔案上，可以有三個型別的事務事件。

 

1、事務結束，已經被commit，之後打過checkpoint檢查點。這種事務記錄在Log File上，但是變化資訊已經被DBWn寫入進資料檔案；

2、事務結束，已經被commit，之後沒有打入checkpint檢查點。這種情況下，Log File已經寫入了日誌專案，資料檔案可能包括髒資料，也可能沒有寫入髒資料；

3、事務未結束，沒有commit。這種時候，資料塊Dirty Block上面是有事務槽資訊，表示未結束事務，是不會將資料寫入到資料檔案中。但是，日誌Log Buffer可能將部分未提交的DML操作專案寫入到Log File中；

 

 

檢查點Checkpoint

 

檢查點Checkpoint是資料庫一致性檢查的一個標記。簡單的說，就是在這個點上，Oracle保證各個檔案（資料、控制、日誌等）是一致的。檢查點的作用就是在進行例項恢復的時候，告訴SMON程式，這個點之前的內容不需要進行恢復。

 

 

前滾和回滾介紹

 

 

“前滾和回滾”是Oracle資料庫例項發生意外崩潰，重新啟動的時候，由SMON進行的自動恢復過程。下面透過模擬例項和講解介紹這個過程。

 

 

失敗前場景說明

 

 

日誌中記錄過程如下：

 

1、事務A進行之後，結束commit。之後系統進行了一次checkpoint A；

2、Checkpoint之後，進行事務B，結束commit；

3、進行事務C，C事務量較大，其中進行了一定量的Redo Log檔案寫入。之後系統斷電；

 

 

1、系統啟動過程，進入例項恢復階段

 

當例項意外中斷的時候，各型別檔案，包括控制檔案、資料檔案和日誌檔案上，會存在不一致的問題。這種不一致主要體現在SCN值的差異上。

 

例項在啟動的時候，經過三階段（nomount、mount和open）。在open之前，會進行這種不一致現象的檢查，如果出現不一致，要啟動SMON程式的恢復流程。

 

SMON是Oracle例項的一個後臺程式，主要負責進行系統監控恢復。進行恢復的依據主要是Redo Log記錄。

 

2、前滾程式

 

SMON首先找到最後SCN記錄的Redo Log File。尋找最後一個打入的Checkpoint。

 

順序找到CheckPoint A之後，表示A之前的所有事務都是完全寫入到資料檔案中，不存在不一致性問題。恢復過程從Checkpoint A開始，Oracle開始依據重做日誌Redo Log的系列條目，進行推進。

 

 

首先遇到了事務B資訊，由於事務B已經commit，所以事務B所有相關的Redo Log條目已經全都寫入到Redo Log File中。所以，按照日誌繼續條目推進，完全可以重演replay，並且應用apply事務B的全部過程。

 

這樣，事務B全部實現，最終將透過DBWn完全寫入到資料檔案中。所以，例項失敗之前提交commit的事務B，完全恢復。

 

 

進入事務C的範疇，由於一部分事務C的Redo Log條目已經進入Redo Log File中，所以在進行前滾的時候，一定會replay到這部分的內容。不過，這部分內容中不可能出現commit的標記。所以，前滾的結果一定是遇到例項突然中斷的那個時點。此時replay的結果是，事務C沒有提交。這樣結束了前滾過程，進入回滾階段。

 

 

3、回滾過程

 

對事務C，要進行回滾過程，釋放所有相關資源。從Undo空間中尋找到舊版本SCN的資料塊資訊，來進行SGA中Buffer Cache資料塊恢復。

 

 

 

4、說說恢復過程的損耗

 

很多時候，由於我們事務規模較大，當出現例項崩潰的時候，重啟所需要的時間很多。有一種經驗說法是，事務有多長，前滾和回滾所消耗的時間有多長×2。而且，如果不能完成SMON恢復過程，資料庫是不能算作正常的Open的。

 

 

SMON的恢復過程是Oracle強制進行的一個過程，即使恢復中發生斷電或者其他中斷失敗事件。Oracle在下一次啟動的時候，還是會繼續這個過程，只有耐心等待。

 

 

透過檢查一些內部檢視（X$檢視），可以觀察到恢復程式和速度，但是絲毫不能影響到最終恢復的過程。

 

 

這個過程雖然可以保證資料一致性，但是也帶來了系統不能啟動，影響生產環境的問題。我們可以透過兩個方式進行緩解：

 

首先，我們在設計開發系統時，要保證事務規模的可控性，不要讓事務規模在技術層面上過大。避免一旦發生崩潰，大規模強制回滾的發生；

 

其次，一旦出現了這個強制回滾，要注意對生產環境的影響。可以採用備庫standby進行頂替，讓主庫安靜的慢慢恢復；