Oracle 資料庫的 ACID 特性核心在於 Redo 機制。本文將從 Redo Log Buffer、LGWR 背景進程、Redo Log File 三大組件切入，深度剖析事務提交、檢查點推進、實例恢復的完整鏈路，幫助 DBA 與開發人員建立扎實的內核認知。
Redo 三大核心組件架構
- Redo Log Buffer（SGA 內）：循環共享記憶體區，以連續順序空間儲存 Redo Entries（重做條目），記錄 INSERT/UPDATE/DELETE/DDL 等所有資料變更。
- LGWR (Log Writer)：專責將 Redo Log Buffer 內容**順序、批次**寫入線上 Redo Log File，降低隨機 I/O 壓力。
- Redo Log File（磁碟）：多組（Group）循環使用，滿寫觸發 Log Switch；歸檔模式下由 ARCn 進程轉存為 Archived Redo Log，支援介質恢復。
為何採用「No-Force-at-Commit」策略？
若每次 COMMIT 都強制將修改塊刷入資料檔，磁碟隨機 I/O 將成為嚴重瓶頸。Oracle 採用 **WAL (Write-Ahead Logging)**：
- 用戶修改資料 → 產生 Redo Entries → 複製到 Redo Log Buffer
- COMMIT 時 → LGWR 強制將對應 Redo 寫入 Redo Log File（確保持久性）
- 修改塊留在 Buffer Cache（髒塊）→ 由 DBWR 稍後批次刷盤
此機制將**隨機寫轉為順序寫**，大幅提升交易吞吐量。
檢查點：縮短恢復時間的關鍵
Checkpoint (CKPT) 事件會通知 DBWR 將特定 SCN (Checkpoint SCN) 之前的所有髒塊刷入資料檔，並更新控制檔與資料檔頭記錄該 SCN。意義在於：
- 此 SCN 之前的 Redo 對崩潰恢復不再需要
- 實例恢復僅需從**最後一次完成的檢查點**開始前滾
- 生產環境**強烈建議啟用歸檔模式**，確保 Redo 不丟失，支援時間點恢復 (PITR)
Log Switch 與檢查點的協同
當線上日誌組寫滿發生 Log Switch 時，會觸發檢查點。在檢查點完成前，該日誌組**不可被重用**（STATUS 顯示 ACTIVE 或 CURRENT）。可透過 V$LOG 監控狀態：
SELECT group#, members, status FROM v$log;
實例恢復流程圖解
- Instance 啟動 → MOUNT 階段讀取控制檔獲取最後 Checkpoint SCN
- OPEN 階段 → SMON 偵測需恢復 → 從 Checkpoint SCN 開始掃描 Redo
- 前滾：重做所有 Committed 與 Uncommitted 變更
- 回滾：利用 Undo 回滾未提交交易，釋放鎖資源
- 資料庫開放服務
調優建議
- Redo Log File 尺寸與組數：避免頻繁 Log Switch（建議切換間隔 15-20 分鐘），配置 4-6 組以上。
- LOG_CHECKPOINT_INTERVAL / LOG_CHECKPOINT_TIMEOUT：控制檢查點頻率，平衡恢復時間與運行期效能。
- 多路複用：Redo Log 成員放置於不同磁碟/控制器，控制檔同樣多路複用，消除單點故障。
理解 Redo 與檢查點的協作機制，是掌握 Oracle 高可用、效能調優與災難恢復的基石。
