生產(chǎn)環(huán)境： SQL Server 2008 R2 Active/Passive Nodes,Windows Server 2008 R2 SP1 Cluster, vSphere 5.x 發(fā)生起始 6 am 接到Application Team報(bào)告 BiztalkMsgBoxDb進(jìn)入suspect模式，不可以訪問。 報(bào)告事件，減少用戶壓力 簡單的和App Manager電話了下，了解

　　生產(chǎn)環(huán)境：

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

　　發(fā)生起始

　　6 am 接到Application Team報(bào)告 BiztalkMsgBoxDb進(jìn)入suspect模式，不可以訪問。

　　報(bào)告事件，減少用戶壓力

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

　　整理一下自己

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

　　察看Error Log,定位起始出錯(cuò)信息

　　6:40 am查找到最初的錯(cuò)誤，發(fā)生在成功的 Log backup以后的1分鐘，錯(cuò)誤信息顯示：OS Error導(dǎo)致了LogWriter的log flush (寫日志)失敗。不能寫日志會導(dǎo)致數(shù)據(jù)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.

　　分析錯(cuò)誤：

　　1117 OS錯(cuò)誤，有關(guān)磁盤。日志文件還在，磁盤沒有滿?？梢钥紤]對log file遷移。

　　第一次嘗試 DBCC Repair

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

　　命令 ALTER DATABASE [xxxxxx]SET EMERGENCY;

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

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

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

　　第二次嘗試 遷移日志文件

　　遇到 resource lock 的問題，通常的 第一反應(yīng)都是kill 或者 重啟資源。這里限于自己技能不足或者沒有建立正確的methodology,第一時(shí)間發(fā)現(xiàn)不了lock的資源，所以選擇了重啟資源

　　應(yīng)為是Windows Cluster,所以不用detach/attach數(shù)據(jù)庫，直接failover到passive server,數(shù)據(jù)庫在failover后等效的重起和實(shí)例恢復(fù)了。現(xiàn)在日志文件可寫，數(shù)據(jù)庫恢復(fù)到Active.

　　暫時(shí)解決了問題，然后將數(shù)據(jù)庫switch over到原來的 active服務(wù)器。沒有出錯(cuò)，證明不是磁盤本身的問題。可能是磁盤接口問題。同時(shí)查看了event viewer除了log backup沒有發(fā)現(xiàn)其他。Sp_who2也沒有發(fā)現(xiàn)可疑的database lock排除了數(shù)據(jù)庫進(jìn)程鎖住數(shù)據(jù)庫或者logfile.

　　建立問題

　　7 am,讓Server Team檢查磁盤，懷疑EVA SAN出問題。 現(xiàn)在只知道起始錯(cuò)誤和解決方法。作為一個(gè)問題，留給Problem Manager繼續(xù)更進(jìn)，用來避免以后發(fā)生同樣的問題。

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