SQL Server 資料庫進入 SUSPECT 模式完整排查與修復實錄

生產環境清晨 6 點接獲警報：BizTalkMsgBoxDb 進入 SUSPECT 狀態，應用層全面中斷。本文完整記錄從錯誤日誌分析、嘗試修復、決策權衡到最終透過叢集容錯移轉恢復服務的全過程，並總結標準化排查方法論，供 DBA 面對同類災難時參考。

環境與初始狀況

• SQL Server 2008 R2 Active/Passive 叢集
• Windows Server 2008 R2 SP1 + vSphere 5.x
• 錯誤發生於 03:15:56，緊接成功的記錄備份後 1 分鐘

錯誤日誌關鍵訊息

Error: 17053, Severity: 16, State: 1.
LogWriter: Operating system error 1117 encountered.
Write error during log flush.
Error: 9001, Severity: 21, State: 4.
The log for database 'BizTalkMsgBoxDb' is not available.

錯誤分析與決策樹

OS Error 1117 解讀

錯誤碼 1117 代表「裝置 I/O 錯誤」，指向磁碟子系統。經確認：記錄檔存在、磁碟空間充足、無其他事件檢視器錯誤，初步判定為 SAN 存儲暫時性 I/O 抖動或路徑故障，而非邏輯損壞。

第一嘗試：DBCC REPAIR_ALLOW_DATA_LOSS（放棄）

• 需先 ALTER DATABASE ... SET EMERGENCY，但資料庫被鎖定無法執行。
• 若強行修復，100 GB+ 資料庫重建記錄可能耗時數小時，違反 RTO/SLA。
• 更關鍵：未經業務方確認可接受丟失近 15 分鐘交易（記錄備份頻率），貿然修復風險極高。

教訓：DBCC REPAIR 不應為第一選項，必須先確認檔案損壞與 I/O 異常來源。

第二嘗試：叢集容錯移轉（成功）

• 因為是 Windows 叢集，直接將資源群組容錯移轉至被動節點，等同實例重啟與資料庫復原。
• 移轉後記錄檔可寫入，資料庫自動回到 ONLINE 狀態。
• 再切回原主動節點，無錯誤發生，排除實體磁碟壞軌，鎖定為磁碟路徑/介面卡暫時性問題。

事後根因分析與問題管理

• 要求儲存團隊檢查 EVA SAN 固件、多路徑軟體、纖維通道錯誤計數器。
• 建立 Problem Record 追蹤永久修正（如升級 MPIO、調整逾時參數）。
• 補充：sp_who2 排除封鎖進程，Event Viewer 僅見記錄備份事件。

標準化 SUSPECT 排查方法論

1. 確認磁碟/儲存層：Event Viewer、SAN 管理介面、I/O 延遲計數器。
2. 確認資料庫進程鎖定：sp_who2、sys.dm_tran_locks、應用連線狀態。
3. 確認檔案邏輯損壞：DBCC CHECKDB（僅讀模式）、頁面驗證選項。
4. 依嚴重度制定方案：(1) 路徑切換/容錯移轉 > (2) 解除鎖定 > (3) 頁面修復/重建記錄 > (4) 還原備份。
5. 風險溝通：任何可能遺失資料的操作，必須書面確認業務可接受範圍。

最後防線永遠是：經驗證可用的完整備份組合（完整+差異+記錄）與定期還原演練。