SQL Server 資料庫修復實戰：LDF 日誌檔損毀的資料完整恢復流程

2004 年 11 月 12 日，客戶伺服器發生 RAID 故障，經搶救後資料檔案（MDF）損壞輕微，但交易日誌檔（LDF）嚴重損毀無法使用。本文記錄如何在無可用日誌檔的情況下，完整恢復資料庫資料的實戰操作流程。

故障現象與初步處理

1. 建立一個同名的新資料庫。
2. 停止 SQL Server 服務。
3. 用原資料庫的 MDF 檔案覆蓋新建資料庫的 MDF 檔案。
4. 重新啟動 SQL Server 服務。
5. 企業管理器中該資料庫顯示為「置疑」狀態。

核心修復腳本（於查詢分析器執行）

USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES', 1 RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS = 32768 WHERE NAME = '置疑的資料庫名'
GO
SP_DBOPTION '置疑的資料庫名', 'single user', 'true'
GO
DBCC CHECKDB('置疑的資料庫名')
GO
UPDATE SYSDATABASES SET STATUS = 28 WHERE NAME = '置疑的資料庫名'
GO
SP_CONFIGURE 'ALLOW UPDATES', 0 RECONFIGURE WITH OVERRIDE
GO
SP_DBOPTION '置疑的資料庫名', 'single user', 'false'
GO

後續處理與資料導出

執行上述腳本後，資料庫仍顯示「置疑」。此時採取以下步驟：

1. 新建一個空的目標資料庫。
2. 使用 DTS 匯入/匯出精靈，將置疑資料庫中的所有資料導入新資料庫。
3. 開啟新資料庫驗證，所有資料完整找回。

關鍵點總結

• 允許系統表更新（ALLOW UPDATES）是修改 SYSDATABASES 狀態的前提，操作極高風險，務必在備份後執行。
• 單用戶模式確保修復過程無其他連線干擾。
• DBCC CHECKDB 檢查資料庫一致性，若報錯需視具體錯誤進一步處理。
• DTS 資料轉移 是繞過置疑狀態、提取資料的關鍵手段。

警告：直接修改系統表屬非官方支援操作，生產環境務必先嘗試官方修復流程（如從備份還原），或聯繫 Microsoft 技術支援。本案例為特殊情況下的應急方案。