深入解析 Oracle 資料庫前滾與回滾的產生機制

在 Oracle 資料庫運作中，若資料尚未提交卻已被 DBWn 進程寫入資料檔案，會發生什麼情況？本文將透過案例分析，深入探討這一核心機制。

案例分析：DBWn 寫入髒資料與 Commit 無關

在一個交易過程中，Online Redo Log 會優先記錄交易修改的資料區塊相關資訊，被修改的資料區塊暫存在 Database Buffer Cache 中。當 Buffer Cache 寫滿或觸發 Checkpoint 等條件時，DBWn 進程會將這些快取的資料區塊寫入資料檔案，但此時該交易可能仍未提交。因此，資料檔案中可能同時存在已提交與未提交的資料區塊，而原始資料區塊的鏡像則存放在 Undo Segment 中。關鍵在於：DBWn 寫入髒資料時，不關心該交易是否已提交，也無需干預。

這導致兩種現象並存：

• 已提交的資料，尚未寫入資料檔案
• 未提交的資料，卻已被寫入資料檔案

引發前滾與回滾的根本原因

核心在於 Commit 後寫 Redo Buffer 與觸發 LGWR 寫 Redo Buffer 的差異。

事務執行完畢後，操作會寫入 Redo Buffer 和 Undo 中，兩者預設狀態皆為 Active（未提交）。Commit 操作會將此前所有事務操作強制寫入 Redo Log File，並將 Redo Buffer 與 Undo 中的事務標記修改為 Inactive（已提交）。

而 LGWR 進程在觸發時，同樣將 Redo Buffer 寫入 Redo File，但 Redo File 本身不記錄任何標識資訊，LGWR 寫到哪裡就是哪裡，即使掉電也無妨。LGWR 是 Oracle 後台進程，對 Oracle 透明，故無需額外標記。

Commit 是唯一能讓前台與後台通訊的指令，因此 Oracle 必須掌握各事務讀寫狀態，透過 Redo 與 Undo 中的提交標識來判斷：已提交但未寫入資料檔案 → 前滾；未提交但已寫入資料檔案 → 回滾。

Oracle 崩潰恢復步驟

1. Rolling Forward（前滾）：實例失效導致 SGA 記憶體資訊遺失，但 Online Redo Log 仍保存事務資訊（含 Committed/Uncommitted）。SMON 依據 Redo Log 記錄完成對 Datafile 的修改，確保已提交資料寫入資料檔案。
2. 資料庫正常 Open：此時用戶可正常連接、訪問已恢復的 Committed Data。屬於 Unrecoverable Transaction 的 Uncommitted Data 會被 Oracle 加鎖，不可訪問。
3. Rolling Back（回滾）：若有進程訪問這些被鎖定的資料，SMON 會對資料區塊執行 Rollback，從資料檔案中撤銷未提交卻已寫入的資料。

理解這一機制，才能對症下藥，保障資料庫穩定運行。