前言
媒體恢復是 Oracle 最核心、最複雜的恢復機制。本文基於 Controlfile、Redo Log、Datafile Dump 內容逆向推演，勾勒出 10 階段內部流程，助您建立心智模型，增強故障處理信心。
十階段媒體恢復內部流程
- 確定 Media Recovery Start SCN
- 掃描所有需恢復資料檔檔頭，取最小 Checkpoint SCN 作為起始點。
- 若該 SCN 落在檔案 Offline SCN 範圍 內，則採用 Offline End SCN。
- 檢查 Checkpoint Structure 確認啟動 Thread 數
- 在 Start SCN 的 Checkpoint Structure 中統計有多少 Redo Thread 已啟動（RAC 多實例環境）。
- 為每個啟動 Thread 分配 Log Buffer
- 在 SGA 中為參與恢復的每個 Thread 保留專用 Redo 讀取緩衝區。
- 開啟所需 Redo Log 檔案
- 線上日誌：系統自動開啟。
- 歸檔日誌：提示操作員輸入檔案路徑（或自動從
LOG_ARCHIVE_DEST 讀取）。
- 分配獨佔 Media Recovery Lock
- 對每個參與恢復的資料檔加獨佔鎖（Enqueue），防止並發修改破壞一致性。
- 設定資料檔 Fuzzy Bit
- 標記資料檔處於「模糊/恢復中」狀態，防止被正常開啟讀寫。
- Checkpoint Bitvec 決定初始啟動 Thread
- 根據位向量資訊確認哪些 Thread 需優先應用 Redo。
- Thread 並行讀取並應用 Redo
- 各 Thread 讀取對應 Redo 記錄，應用至資料區塊（含 Undo 區塊），推進區塊 SCN。
- 媒體恢復檢查點
- 日誌切換時：每次切換 Redo Log 檔案（Thread 邊界），觸發 Media Recovery Checkpoint，更新控制檔與資料檔頭 Checkpoint SCN。
- 達到 Stop SCN 時：資料檔恢復至目標 SCN，觸發最終 Checkpoint，資料檔頭 Checkpoint 推進至 Stop SCN。
- 完成媒體恢復
- 所有 Thread 均達到各自 Stop SCN。
- 清除資料檔 Fuzzy Bit（重置為
0x0000.00000000）。
- 更新控制檔與所有資料檔頭，標記資料庫整體一致（
STATUS = 'CURRENT'）。
關鍵技術細節補充
- Fuzzy Bit 機制：允許資料檔在備份/恢復期間處於不一致狀態，恢復完成後統一推進 Checkpoint 達到一致性。
- Thread 與 Redo 並行：RAC 環境下，各實例 Redo 獨立生成、獨立應用，Media Recovery 協調多 Thread 並行回放，效能隨 Thread 數線性擴展。
- Stop SCN 來源：
RECOVER DATABASE UNTIL SCN n、UNTIL TIME、UNTIL CANCEL（手動取消時以當前 Redo 末尾為止）。
- 控制檔角色：記錄 Checkpoint 進度、Thread 狀態、歸檔日誌歷史，是恢復協調的中樞。
實務驗證與觀測
-- 觀測恢復進度
SELECT * FROM V$RECOVERY_PROGRESS;
SELECT * FROM V$RECOVERY_STATUS;
-- 檢查 Fuzzy Bit 狀態
SELECT file#, fuzzy FROM V$DATAFILE_HEADER;
-- 確認恢復後一致性
SELECT status, checkpoint_change#, checkpoint_time FROM V$DATAFILE_HEADER;
總結
媒體恢復本質是：從最早 Checkpoint 開始，多 Thread 並行重演 Redo，透過周期性 Checkpoint 推進一致性邊界，最終清除 Fuzzy Bit 宣告全庫一致。理解此流程，能讓您在面對 ORA-01113、ORA-01110、ORA-00283 等恢復錯誤時，精準定位卡在哪個階段，採取針對性對策（補檔、跳過、允許損失資料等）。
