您现在的位置：程式碼之家 >> 數據庫知識 > >> SQL Server 資料庫 >> 關於SqlServer

SQL Server 資料庫進入 Suspect 模式的排查與解決實戰

編輯：關於SqlServer

事件背景

生產環境：SQL Server 2008 R2 Active/Passive 叢集、Windows Server 2008 R2 SP1、vSphere 5.x。

凌晨 6 點，應用團隊報告 BizTalkMsgBoxDb 進入 Suspect 模式，無法存取。第一時間與應用經理溝通，瞭解業務影響範圍，記錄發生時間、錯誤描述及近期變更，並由事件管理員統一對外通報，有效降低團隊恐慌與重複溝通成本。

初步研判與錯誤日誌分析

快速腦力激盪可能原因：檔案群損壞、磁碟空間不足或 SAN 故障、備份可用性。隨即檢視 SQL Server Error Log，定位到最早錯誤發生於一次成功的記錄備份後 1 分鐘：

2014-03-17 03:15:56.05 spid5s Error: 17053, Severity: 16, State: 1.
2014-03-17 03:15:56.05 spid5s LogWriter: Operating system error 1117 (failed to retrieve text for this error. Reason: 15105) encountered.
2014-03-17 03:15:56.05 spid5s Write error during log flush.
2014-03-17 03:15:56.05 spid79 Error: 9001, Severity: 21, State: 4.
2014-03-17 03:15:56.05 spid79 The log for database 'BizTalkMsgBoxDb' is not available...

OS Error 1117 指向磁碟 I/O 層面。經確認：記錄檔存在、磁碟未滿，初步判斷為磁碟介面或 SAN 暫時性故障，考慮嘗試遷移記錄檔。

第一次嘗試：DBCC Repair —— 果斷放棄

嘗試 ALTER DATABASE SET EMERGENCY 失敗，提示資料庫被鎖定。若強行進入 Emergency 模式執行 DBCC CHECKDB ... REPAIR_ALLOW_DATA_LOSS，將嘗試利用現有記錄恢復一致性，若記錄受損則會重建記錄。對於 100 GB 以上的資料庫，重建記錄可能耗時數小時，嚴重違背 RTO 與 SLA。更關鍵的是：未與業務方確認是否可接受丟失最近 15 分鐘的交易（雖然當時用戶尚在睡眠）。

事後反思：武斷假設記錄檔損壞並將 DBCC Repair 作為首選手段是錯誤的。正確方法論應為：先確認檔案是否損壞、協同伺服器團隊排查 I/O 異常，再評估修復策略與數據風險。

第二次嘗試：遷移記錄檔 —— 透過叢集容錯移轉解決

遭遇資源鎖定問題，受限於技能與方法論，未能快速定位鎖定來源，選擇重啟資源。因為是 Windows 叢集，直接執行 Failover 到被動節點，資料庫實例相當於重啟並完成復原，記錄檔恢復可寫，資料庫回到 Online 狀態。隨後切回原主節點未報錯，排除磁碟實體故障，鎖定為磁碟介面或驅動層暫時性問題。Event Viewer 與 sp_who2 均未發現異常鎖定。