保持數據一致性和完整性，是每一款成功商業數據庫軟件都必須要做到的基本要求。從故障中恢復，保證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進行頂替，讓主庫安靜的慢慢恢復；