SQL Server 資料庫崩潰災難恢復實戰：從附加資料庫到緊急模式重建日誌

前言：災難恢復的核心挑戰

任何資料庫系統都無法完全避免崩潰，即便部署叢集或雙機熱備，單點故障風險依然存在。大多數企業難以負擔高昂硬體成本，因此掌握資料庫崩潰後的資料搶救技巧至關重要。

最佳情境：資料與日誌檔案完好

• 直接使用 sp_attach_db 將資料檔（.mdf）與日誌檔（.ldf）附加至新資料庫。
• 或於停機時將所有資料檔（含 master 等系統資料庫）複製回原路徑（不推薦，sp_attach_db 較標準）。

常見情境：未完成交易與髒頁導致附加失敗

崩潰時系統來不及將交易寫入磁碟，導致 sp_attach_db 失敗。此時需依賴災難恢復計畫：還原最新完整備份 → 差異備份 → 交易日誌備份 → 若作用中日誌可讀，可恢復至崩潰前狀態。

最棘手情境：無可用備份、日誌損壞、儲存子系統故障

若無專職 DBA、備份過舊、作用中日誌不可用，且崩潰主因為儲存子系統故障（幾乎無可用日誌），可嘗試以下進階搶救方案（前提：資料檔 .mdf 仍存在）：

方案一：sp_attach_single_file_db 單檔附加

嘗試僅附加 .mdf 檔案，SQL Server 會嘗試重建日誌。若資料庫剛好執行過 CHECKPOINT，成功機率較高。

方案二：緊急模式重建日誌（核心搶救技巧）

1. 允許系統表更新：
   USE master; GO
sp_configure 'allow updates', 1;
reconfigure with override; GO
2. 將資料庫狀態設為緊急模式（32768）：
   UPDATE sysdatabases SET status = 32768 WHERE name = 'YourDB';
3. 重啟 SQL Server 服務，系統會嘗試重建日誌檔。
4. 若無錯誤，設為單一使用者模式執行 DBCC 檢查修復：
   sp_dboption 'YourDB', 'single user', 'true';
DBCC CHECKDB('YourDB');
5. 修復完成後恢復正常狀態（status=28 或使用 sp_resetstatus），關閉系統表更新選項。

警告：進行中交易必定遺失，資料可能受損。DBCC CHECKDB 可能需使用 REPAIR_ALLOW_DATA_LOSS 選項完成修復，損壞資料只能捨棄。

總結

定期備份、驗證備份可用性、建立災難恢復演練流程，永遠是成本最低、風險最小的策略。上述技巧僅為最後防線，請謹慎使用。