SQL Server 遺失記錄檔 (LDF) 資料庫緊急復原實戰：兩大經典方案完整還原攻略

前言

誤刪交易記錄檔 (.ldf) 是 DBA 職涯中最驚心動魄的時刻之一。資料庫進入 SUSPECT (置疑) 狀態，無法正常掛載。本文提供兩大經典復原方案：標準緊急模式修復法 與 實戰案例深度還原法 (含 DTS/SSIS 資料遷移)，並解析關鍵風險控制點。

核心原理：緊急模式 (EMERGENCY MODE)

• 繞過正常啟動流程，僅掛載資料檔 (.mdf)，**不驗證記錄檔一致性**
• 資料庫設為 SINGLE_USER、READ_ONLY (舊版) 或 READ_WRITE (新版)
• 允許執行 DBCC CHECKDB 修復、資料匯出、結構腳本產生
• **風險**：可能讀取到未提交/部分寫入/邏輯不一致的資料，**務必全量匯出驗證後重建**

方案一：標準緊急模式修復腳本 (適用 SQL 2000/2005/2008)

-- 1. 建立同名空資料庫 (僅為取得檔案鎖定權限)
CREATE DATABASE [RecoverDB];
GO

-- 2. 停止 SQL Server 服務 (net stop MSSQLSERVER)

-- 3. 用原始 .mdf 覆蓋新建資料庫的 .mdf
--    複製原始 RecoverDB.mdf → 覆蓋 C:\Data\RecoverDB.mdf

-- 4. 啟動 SQL Server 服務
--    資料庫將顯示為 SUSPECT (置疑)

-- 5. 進入緊急模式修復
USE MASTER;
GO
EXEC sp_configure 'allow updates', 1; RECONFIGURE WITH OVERRIDE;  -- 允許直接更新系統表 (舊版需求)
GO

UPDATE sysdatabases SET status = 32768 WHERE name = 'RecoverDB';  -- 32768 = EMERGENCY MODE
GO

EXEC sp_dboption 'RecoverDB', 'single user', 'true';  -- 單用戶模式
GO

DBCC CHECKDB ('RecoverDB');  -- 檢查並嘗試修復 (可加 REPAIR_ALLOW_DATA_LOSS)
GO

-- 重置狀態
UPDATE sysdatabases SET status = 28 WHERE name = 'RecoverDB';  -- 28 = 正常狀態
GO

EXEC sp_configure 'allow updates', 0; RECONFIGURE WITH OVERRIDE;
GO

EXEC sp_dboption 'RecoverDB', 'single user', 'false';
GO

-- SQL 2005+ 簡化版 (不需 allow updates)
-- ALTER DATABASE RecoverDB SET EMERGENCY;
-- ALTER DATABASE RecoverDB SET SINGLE_USER;
-- DBCC CHECKDB ('RecoverDB', REPAIR_ALLOW_DATA_LOSS);
-- ALTER DATABASE RecoverDB SET MULTI_USER;
-- ALTER DATABASE RecoverDB SET ONLINE;

方案二：實戰深度還原 — 從誤刪 LDF 到業務零資料遺失

案例背景

• 資料庫 XXX，記錄檔 XXX_Log.ldf 增長至 3 GB
• 嘗試縮減無效，**誤刪除 .ldf 檔案**
• 資料庫進入 SUSPECT，**從未備份**
• 僅有半年前遷移的舊伺服器備份 (缺少大量近期資料/物件)

完整復原時間軸

1. 建立緊急模式資料庫：
   • 停止服務 → 移走原始 .mdf → 建立同名空資料庫 → 停止服務 → 覆蓋回原始 .mdf → 啟動服務
   • 執行緊急模式 T-SQL (見方案一)，資料庫進入 EMERGENCY + SINGLE_USER
2. DBCC CHECKDB 驗證結構：
   • 輸出顯示各系統表列數、頁數，**結構基本完整**，無嚴重配置錯誤
3. 重置狀態：
   • EXEC sp_resetstatus 'XXX' (SQL 2005+ 推薦，替代手動 UPDATE sysdatabases)
   • 關閉 allow updates，資料庫恢復 ONLINE
4. 資料遷移 — 關鍵決策點：
   • 嘗試 DTS/SSIS 「複製物件與資料」 → 失敗 (僅複製結構、無資料、報錯)
   • 嘗試 「複製資料表與檢視」 → 部分表資料遺失
   • 最終方案：逐表「指定查詢傳輸」 — 缺哪張表補哪張，視圖/SP 以腳本重建
5. 建立乾淨目標資料庫 XXX_Lost：
   • 匯入所有表資料、重建視圖/預存程序/函數/觸發器
   • 驗證資料筆數、檢查碼、應用功能測試通過
6. 剪換上線：離線舊資料庫 → 重命名 XXX_Lost → XXX → 更新連線字串 → 業務恢復

關鍵風險控制點 (必讀)

預防勝於治療：LDF 保護鐵律

1. 完整復原模式 + 定期記錄備份 (每 15~60 分鐘) — 記錄檔自動截斷，不會暴增
2. 監控記錄檔大小與 VLF 數量 — 設定告警閾值 (如 > 10 GB 或 VLF > 500)
3. 禁止直接刪除 .ldf 檔案 — 作業手冊明文禁止，權限控制 (服務帳號擁有檔案，DBA 帳號僅讀取)
4. 定期演練「無備份、無 LDF」復原演練** — 將方案一、二腳本納入演練清單