成熟丰满熟妇高潮XXXXX,人妻无码AV中文系列久久兔费 ,国产精品一国产精品,国精品午夜福利视频不卡麻豆

您好,歡迎來到九壹網(wǎng)。
搜索
您的當(dāng)前位置:首頁SQLServer數(shù)據(jù)庫Suspect解決

SQLServer數(shù)據(jù)庫Suspect解決

來源:九壹網(wǎng)

生產(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ù)