Oracle 媒體恢復是資料庫核心恢復機制，其內部流程極為複雜。本文基於控制檔、重做日誌、資料檔的 Dump 內容逆向推導，系統梳理媒體恢復的十大關鍵步驟，幫助 DBA 建立對恢復機制的深層理解，增強生產故障處理信心。
媒體恢復十大核心步驟
- 獲取 Media Recovery Start SCN
掃描所有資料檔頭，取最小的 Checkpoint SCN 作為起始 SCN。若該 SCN 落於資料檔 Offline SCN 範圍內，則採用 Offline End SCN。
- Checkpoint Structure 檢查 Thread 啟動數
在 Media Recovery SCN 點的 Checkpoint Structure 中，確認有多少 Thread（執行緒）已啟動。
- 分配 Log Buffer
為步驟 2 中每個啟動的 Thread 分配專屬 Log Buffer。
- 開啟 Redo Log 檔案
- 線上日誌：系統自動開啟
- 歸檔日誌：提示管理員輸入檔案名稱
- 分配獨佔型 Media Recovery Lock
為每個需執行媒體恢復的資料檔分配獨佔鎖，防止併發衝突。
- 設定資料檔 Fuzzy Bit
標記資料檙處於恢復中（不一致）狀態。
- Checkpoint Bitvec 決定初始啟動 Thread
透過位向量確認哪些 Thread 需開始應用 Redo。
- Thread 讀取並應用 Redo
各 Thread 讀取對應 Redo 記錄並應用至資料庫區塊。
- Media Recovery Checkpoint 觸發
兩種情況觸發檢查點：
- Redo 檔案切換時
- 資料檔達到 Stop SCN 時，檔頭 Checkpoint 推進至該值
- 完成 Media Checkpoint，恢復結束
所有 Thread 完成 Redo 應用並達到資料檔 Stop SCN，Fuzzy Bit 清零（重置為 0x0000.00000000），更新資料檔頭與控制檔，宣告資料庫整體一致。
關鍵技術洞見
- SCN 為核心錨點：從 Start SCN 到 Stop SCN，全程以 SCN 串聯恢復進度
- Thread 並行恢復：Oracle Parallel Server / RAC 環境下多 Thread 並行應用 Redo
- Fuzzy Bit 機制：保證恢復過程中資料檔狀態可識別，防止誤判為一致
- Checkpoint 推進策略：定期推進降低故障重啟後的恢復時間
實務價值
理解內部流程可幫助 DBA：
- 預估恢復時間（根據 Redo 量、Thread 數、硬體效能）
- 診斷恢復卡住原因（鎖等待、Redo 缺失、Fuzzy Bit 異常）
- 優化備份策略（縮短 Start SCN 與備份點差距）
- 應對面試與技術交流中的核心原理提問
參考致謝
本文結合 Google 搜尋到的 Oracle Internal 技術文章與 Dump 檔案分析整理而成，感謝原作者的無私分享。
