SQL Server 2000 資料庫進入 SUSPECT 模式的緊急修復步驟

現象

企業管理員中資料庫標示為 Suspect (置疑)，無法正常存取。常見原因：記錄檔損毀、磁碟故障、非正常關機導致交易未完成。

修復流程（資料風險自負，務必先備份檔案）

1. 分離資料庫：企業管理員 → 右鍵資料庫 → 所有工作 → 分離資料庫。
2. 備份實體檔案：複製 .mdf、.ldf 至安全位置。
3. 建立同名空資料庫：同檔案路徑、同邏輯名稱建立新資料庫。
4. 停止 SQL Server 服務。
5. 用備份的 .mdf/.ldf 覆蓋新建資料庫檔案。
6. 啟動 SQL Server 服務。此時資料庫仍會顯示 Suspect。
7. 執行緊急修復腳本（修改資料庫名稱）：

USE MASTER;
GO
EXEC sp_configure 'allow updates', 1; RECONFIGURE WITH OVERRIDE;
GO
UPDATE sysdatabases SET status = 32768 WHERE name = 'YourDB_Name';  -- 設為 Emergency 模式
GO
EXEC sp_dboption 'YourDB_Name', 'single user', 'true';
GO
DBCC CHECKDB('YourDB_Name');  -- 檢查並嘗試修復
GO
UPDATE sysdatabases SET status = 28 WHERE name = 'YourDB_Name';  -- 恢復正常模式
GO
EXEC sp_configure 'allow updates', 0; RECONFIGURE WITH OVERRIDE;
GO

關鍵狀態值說明

後續驗證

• 執行 DBCC CHECKDB('YourDB_Name') 確認無錯誤。
• 檢查關鍵業務資料完整性。
• 立即執行完整備份 + 記錄備份，建立可靠復原點。
• 排查根因：磁碟健康 (SMART)、記錄檔自動成長設定、備份策略是否執行。

現代版本建議

SQL Server 2005+ 提供 EMERGENCY、SINGLE_USER、REPAIR_ALLOW_DATA_LOSS 更完整的修復選項：

ALTER DATABASE YourDB SET EMERGENCY;
ALTER DATABASE YourDB SET SINGLE_USER;
DBCC CHECKDB('YourDB', REPAIR_ALLOW_DATA_LOSS);  -- 最後手段，可能遺失資料
ALTER DATABASE YourDB SET MULTI_USER;

預防勝於治療

• 啟用 CHECKSUM 頁面驗證（ALTER DATABASE ... SET PAGE_VERIFY CHECKSUM）。
• 定期 DBCC CHECKDB 排程（建議每週）。
• 記錄檔固定大小成長，避免頻繁自動成長造成碎片。
• 備份驗證：RESTORE VERIFYONLY 定期測試。

警示

REPAIR_ALLOW_DATA_LOSS 會刪除損毀頁面，導致資料遺失。 僅在無備份可還原且業務接受遺失時使用。生產環境首選：從最後可用備份還原 + 記錄備份前滾。