SQL Server 數據庫 Suspect 解決案例

 　　生產環境：

　　SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x

　　發生起始

　　6 am 接到Application Team報告 BiztalkMsgBoxDb進入suspect模式，不可以訪問。

　　報告事件，減少用戶壓力

　　簡單的和App Manager電話了下，了解他們Apps層面down time,在Ticket中錄入大概發生時間，事件描述，最近有沒有發生過任何變更事件。如果沒有Ticket系統，請群發email給相關人員。電話Incident Manager管理所有的事件更新，這樣做的好處：使驚慌失措的人們知道發生了什麼，減少他們的壓力。

　　整理一下自己

　　6:30 am很多人的電話總讓自己神經緊張，簡單的brainstorm一下suspect可能發生的原因：文件組(數據和日志)的損壞?磁盤爆滿/SAN Disk出錯?備份還在吧?

　　察看Error Log,定位起始出錯信息

　　6:40 am查找到最初的錯誤，發生在成功的 Log backup以後的1分鐘，錯誤信息顯示：OS Error導致了LogWriter的log flush (寫日志)失敗。不能寫日志會導致數據suspect.

　　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 error1117(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' isnot available. Check the event log for related error messages. Resolve anyerrors and restart the database.

　　2014-03-17 03:15:56.05 spid85 Error: 9001, Severity: 21, State: 4.

　　分析錯誤：

　　1117 OS錯誤，有關磁盤。日志文件還在，磁盤沒有滿。可以考慮對log file遷移。

　　第一次嘗試 DBCC Repair

　　(任何嘗試的基礎都是要明白：你的動作，不會使情況變得更糟糕)

　　命令 ALTER DATABASE [xxxxxx]SET EMERGENCY;

　　命令出錯， 數據庫被鎖，不能alter database ,直接放棄DBCC CHECKDB (N'xxxxxxx', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;修復。

　　為什麼要放棄： DBCC Repair 要求數據庫在 emergency模式下，它會試圖利用現有log 把數據庫恢復到一致性上(consistent recover)。如果 log有問題， 那麼它 會重建 log ( 個人認為這就是repair allow data loss的意思) .對於一個100 GB以上的數據庫， rebuild log可能花費數小時，考慮到recovery time object (RTO)和 SLA (service level agreement) , 都不允許數據庫 downtime 很久 (事後的反思)。幸運的是不能alter database,錯誤信息直接指明了database log locked, 暗示了數據庫 log可能沒有 corrupt, 那麼沒有必要著急dbcc repair了。

　　事後反思，武斷的認為log file corrupted 是錯誤的，dbcc repair作為 methodology 的第一步也是不合時宜的，應為沒有向用戶確認是否可以丟失過去15分鐘的active transaction (雖然客戶還在睡覺) ( 每15 分鐘的事務日志備份)，更何況它還會讓數據庫 downtime更久，8點上班前未必恢復的了，可能都沒有database backup restore快。作為methodology第一步應該首先確認是否file corrupted 並且聯系server team是否有IO異常。

　　第二次嘗試 遷移日志文件

　　遇到 resource lock 的問題，通常的 第一反應都是kill 或者 重啟資源。這裡限於自己技能不足或者沒有建立正確的methodology,第一時間發現不了lock的資源，所以選擇了重啟資源

　　應為是Windows Cluster,所以不用detach/attach數據庫，直接failover到passive server,數據庫在failover後等效的重起和實例恢復了。現在日志文件可寫，數據庫恢復到Active.

　　暫時解決了問題，然後將數據庫switch over到原來的 active服務器。沒有出錯，證明不是磁盤本身的問題。可能是磁盤接口問題。同時查看了event viewer除了log backup沒有發現其他。Sp_who2也沒有發現可疑的database lock排除了數據庫進程鎖住數據庫或者logfile.

　　建立問題

　　7 am,讓Server Team檢查磁盤，懷疑EVA SAN出問題。 現在只知道起始錯誤和解決方法。作為一個問題，留給Problem Manager繼續更進，用來避免以後發生同樣的問題。

　　總結：遇到 log file 導致的 數據庫掛起，解決方法學首先是(1)確認磁盤問題，然後是(2 ) 確認數據庫process lock,然後是(3)確認是否 corrupt, 這些 check up 做完後再針對(1) (2)(3) 提出解決方案。從(1) 到 (3)嚴重性也越高， 所以恢復後數據丟失的可能性也越高。要和客戶確認在線修復的風險。最後的稻草自然是平時完備的數據備份方案和定期的數據庫恢復執行計劃。