生產(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)告事件,減少用戶壓力 簡(jiǎn)單的和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)告事件,減少用戶壓力
簡(jiǎn)單的和App Manager電話了下,了解他們Apps層面down time,在Ticket中錄入大概發(fā)生時(shí)間,事件描述,最近有沒有發(fā)生過任何變更事件。如果沒有Ticket系統(tǒng),請(qǐng)群發(fā)email給相關(guān)人員。電話Incident Manager管理所有的事件更新,這樣做的好處:使驚慌失措的人們知道發(fā)生了什么,減少他們的壓力。
整理一下自己
6:30 am很多人的電話總讓自己神經(jīng)緊張,簡(jiǎn)單的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 (寫日志)失敗。不能寫日志會(huì)導(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)磁盤。日志文件還在,磁盤沒有滿??梢钥紤]對(duì)log file遷移。
第一次嘗試 DBCC Repair
(任何嘗試的基礎(chǔ)都是要明白:你的動(dòng)作,不會(huì)使情況變得更糟糕)
命令 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模式下,它會(huì)試圖利用現(xiàn)有l(wèi)og 把數(shù)據(jù)庫恢復(fù)到一致性上(consistent recover)。如果 log有問題, 那么它 會(huì)重建 log ( 個(gè)人認(rèn)為這就是repair allow data loss的意思) .對(duì)于一個(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ù)日志備份),更何況它還會(huì)讓數(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ò),證明不是磁盤本身的問題??赡苁谴疟P接口問題。同時(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 做完后再針對(duì)(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ì)劃。
Copyright ? 2019- 91gzw.com 版權(quán)所有 湘ICP備2023023988號(hào)-2
違法及侵權(quán)請(qǐng)聯(lián)系:TEL:199 1889 7713 E-MAIL:2724546146@qq.com
本站由北京市萬商天勤律師事務(wù)所王興未律師提供法律服務(wù)