SQL Server 置疑資料庫修復完整流程：DBCC CHECKDB、單一使用者模式、重建記錄檔

資料庫進入 Suspect (置疑) 狀態通常因檔案損壞、記錄檔遺失、磁碟錯誤。本文提供分級修復流程：標準修復 → 單一使用者修復 → 重建記錄檔 (僅有 MDF)。

階段一：標準修復流程 (有完整 MDF+LDF)

1. 備份現有 .mdf/.ldf (防修復失敗更糟)。
2. 建立同名空資料庫 → 停止服務 → 覆蓋檔案 → 啟動服務 (呈現置疑)。
3. 允許系統表更新：

USE master;
EXEC sp_configure 'allow updates', 1; RECONFIGURE WITH OVERRIDE;

4. 設定緊急模式：

UPDATE sysdatabases SET status = 32768 WHERE name = 'MyDB';

5. 檢查錯誤：

DBCC CHECKDB('MyDB');

6. 若無錯誤或可修復：

EXEC sp_dboption 'MyDB', 'single user', 'true';
DBCC CHECKDB('MyDB', REPAIR_ALLOW_DATA_LOSS);
-- 若提示非單一使用者，重啟服務後重試
DBCC CHECKDB('MyDB');  -- 複查
EXEC sp_resetstatus 'MyDB';  -- 清除置疑旗標
EXEC sp_dboption 'MyDB', 'single user', 'false';
-- 重啟服務驗證

階段二：REPAIR 失敗 → 重建記錄檔 (僅有 MDF 或 LDF 損壞)

1. 建立同名空資料庫 → 停止服務 → 覆蓋 .mdf、刪除 .ldf → 啟動服務。
2. 允許系統表更新 + 設定緊急模式 (同上 3-4 步)。
3. 重啟服務 (確保緊急模式生效)。
4. 重建記錄檔：

DBCC REBUILD_LOG('MyDB', 'D:\Data\MyDB_Log.ldf');

5. 設定單一使用者：

EXEC sp_dboption 'MyDB', 'single user', 'true';

6. 嘗試修復：

DBCC CHECKDB('MyDB', REPAIR_ALLOW_DATA_LOSS);
-- 或 DBCC CHECKTABLE('ProblemTable', REPAIR_ALLOW_DATA_LOSS);

關鍵指令對照

風險與事後必做

• 資料遺失：REPAIR_ALLOW_DATA_LOSS 可能刪除損壞頁面資料。
• 記錄鏈中斷：重建記錄檔後，立即執行完整備份 重新建立備份鏈。
• 關閉 allow updates：修復完成後 sp_configure 'allow updates', 0; RECONFIGURE WITH OVERRIDE;。
• 根因分析：檢查磁碟健康 (SMART)、SQL Server 錯誤日誌、Windows 事件檢視器，修正硬體/軟體根因。

依嚴重程度選擇修復路徑，務必先備份現有檔案，修復後驗證業務資料完整性。