FCI 雙節(jié)點(diǎn)集群，因?yàn)橥砩霞汗?jié)點(diǎn)間的網(wǎng)絡(luò)中斷過。兩個(gè)節(jié)點(diǎn)都覺得還有一個(gè)節(jié)點(diǎn)宕機(jī)，在各節(jié)點(diǎn)的集群管理中都看到對(duì)方已宕機(jī)。

連接到集群IP。提示 msdb 數(shù)據(jù)庫有問題：

發(fā)現(xiàn)MSDB數(shù)據(jù)庫 “可疑”

msdb 損壞了，mssql 錯(cuò)誤日志和代理日志也無就法查詢，從windows查看到信息例如以下：

SQL Server 斷言: 文件: <xdes.cpp>，行=3785 失敗的斷言 = 'curr->GetXdesId () == m_xdesId'。

此錯(cuò)誤可能與時(shí)間有關(guān)。假設(shè)又一次執(zhí)行該語句后錯(cuò)誤仍然存在，請(qǐng)使用 DBCC CHECKDB 來檢查數(shù)據(jù)庫的結(jié)構(gòu)是否完整，或又一次啟動(dòng)server以確保內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)未破壞。 在數(shù)據(jù)庫 'msdb' 中撤消日志記錄下的操作時(shí)。在日志記錄 ID (106502:3622:2) 處出錯(cuò)。通常。這一特定故障曾經(jīng)在 Windows 事件日志服務(wù)中會(huì)記錄為錯(cuò)誤。請(qǐng)利用備份還原數(shù)據(jù)庫或文件，或者修復(fù)該數(shù)據(jù)庫。 處理數(shù)據(jù)庫 'msdb' 的日志時(shí)出錯(cuò)。假設(shè)可能，請(qǐng)從備份還原。假設(shè)沒有可用備份，可能須要又一次生成日志。

因?yàn)樵诶?'XdesRMReadWrite::RollbackToLsn' 中錯(cuò)誤發(fā)生 3314。數(shù)據(jù)庫 msdb 已關(guān)閉。在與該數(shù)據(jù)庫的全部連接都中止后，將嘗試又一次啟動(dòng)非快照數(shù)據(jù)庫。 在數(shù)據(jù)庫 'msdb' 中撤消日志記錄下的操作時(shí)，在日志記錄 ID (106502:3614:1) 處出錯(cuò)。通常，這一特定故障曾經(jīng)在 Windows 事件日志服務(wù)中會(huì)記錄為錯(cuò)誤。

請(qǐng)利用備份還原數(shù)據(jù)庫或文件，或者修復(fù)該數(shù)據(jù)庫。

傳遞給數(shù)據(jù)庫 'msdb' 中的日志掃描操作的日志掃描號(hào) (106502:3144:155) 無效。此錯(cuò)誤可能指示數(shù)據(jù)損壞，或者日志文件(.ldf)與數(shù)據(jù)文件(.mdf)不匹配。假設(shè)此錯(cuò)誤是在復(fù)制期間出現(xiàn)的。請(qǐng)又一次創(chuàng)建公布。否則。假設(shè)該問題導(dǎo)致啟動(dòng)期間出錯(cuò)。請(qǐng)從備份還原。 恢復(fù)期間出錯(cuò)，導(dǎo)致數(shù)據(jù)庫“msdb”(4:0)無法又一次啟動(dòng)。請(qǐng)?jiān)\斷并糾正這些恢復(fù)錯(cuò)誤，或者從已知的正確備份中還原。假設(shè)無法更正錯(cuò)誤，或者為意外錯(cuò)誤，請(qǐng)與技術(shù)支持人員聯(lián)系。

可疑推斷?msdb 數(shù)據(jù)庫日志有損壞。

sql server 還有自己主動(dòng)監(jiān)控的一些跟蹤。主要系統(tǒng)錯(cuò)誤和連接錯(cuò)誤等其它重要性錯(cuò)誤信息，查看例如以下：

DECLARE @path NVARCHAR(1000) SELECT @path =PATH FROM sys.traces WHERE id = 1 SELECT * FROM ::fn_trace_gettable(@path, 0)2017-04-07 01:21:36.05 spid95 錯(cuò)誤: 3624，嚴(yán)重性: 20，狀態(tài): 1。 2017-04-07 01:21:36.05 spid95 A system assertion check has failed. Check the SQL Server error log for details. Typically, an assertion failure is caused by a software bug or data corruption. To check for database corruption, consider running DBCC CHECKDB. If you agreed to send dumps to Microsoft during setup, a mini dump will be sent to Microsoft. An update might be available from Microsoft in the latest Service Pack or in a QFE from Technical Support. 2017-04-07 01:21:36.07 spid95 錯(cuò)誤: 3314，嚴(yán)重性: 21，狀態(tài): 3。 2017-04-07 01:21:36.07 spid95 During undoing of a logged operation in database 'msdb', an error occurred at log record ID (106502:3622:2). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database. 2017-04-07 01:21:37.59 spid95 錯(cuò)誤: 9004，嚴(yán)重性: 23，狀態(tài): 6。

2017-04-07 01:21:37.59 spid95 An error occurred while processing the log for database 'msdb'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log. 2017-04-07 01:21:39.11 spid95 錯(cuò)誤: 9004，嚴(yán)重性: 23。狀態(tài): 6。 2017-04-07 01:21:39.11 spid95 An error occurred while processing the log for database 'msdb'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log. 2017-04-07 01:21:40.64 spid95 錯(cuò)誤: 9004，嚴(yán)重性: 23，狀態(tài): 6。 2017-04-07 01:21:40.64 spid95 An error occurred while processing the log for database 'msdb'. If possible, restore from backup. If a backup is not available, it might be necessary to rebuild the log. 2017-04-07 01:21:40.66 spid95 錯(cuò)誤: 3314，嚴(yán)重性: 21，狀態(tài): 5。 2017-04-07 01:21:40.66 spid95 During undoing of a logged operation in database 'msdb', an error occurred at log record ID (106502:3614:1). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database. 2017-04-07 01:21:41.43 spid22s Error: 9003, Severity: 20, State: 6. 2017-04-07 01:21:41.43 spid22s The log scan number (106502:3144:155) passed to log scan in database 'msdb' is not valid. This error may indicate data corruption or that the log file (.ldf) does not match the data file (.mdf). If this error occurred during replication, re-create the publication. Otherwise, restore from backup if the problem results in a failure during startup. 2017-04-07 01:21:41.43 spid22s Error: 3414, Severity: 21, State: 1. 2017-04-07 01:21:41.43 spid22s An error occurred during recovery, preventing the database 'msdb' (4:0) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.

主要幾個(gè)狀態(tài)：3624、3314、9004、3414
基本原因例如以下：

Troubleshooting Error 3313, 3314, 3414, or 3456 (SQL Server)

How to troubleshoot Error 9004 in SQL Server

因?yàn)閙sdb日志備份引起的（發(fā)現(xiàn)msdb數(shù)據(jù)文件有 60+GB！）

如今集群有問題了，相互占用資源。心跳沒起作用。連接數(shù)據(jù)庫內(nèi)部查看節(jié)點(diǎn)能正常連接到當(dāng)中一個(gè)。

select * from sys.dm_os_cluster_nodes SELECT * FROM fn_virtualservernodes();

更重要的是：由于存儲(chǔ)是共享的。系統(tǒng)數(shù)據(jù)庫和用戶數(shù)據(jù)庫都共享！

兩個(gè)節(jié)點(diǎn)用共享存儲(chǔ)，按理說數(shù)據(jù)是一致的。為了使集群能恢復(fù)正常狀態(tài)，打算轉(zhuǎn)移集群。

重新啟動(dòng)server比較好，不用逐個(gè)轉(zhuǎn)移，使其自己主動(dòng)全部資源轉(zhuǎn)移。

重新啟動(dòng)之后！

。

msdb 正常了！！

可是有 3 個(gè)用戶數(shù)據(jù)庫出現(xiàn)了 “可疑”。！

沒辦法。出現(xiàn)了就僅僅能修復(fù)吧。。設(shè)置 “緊急” 模式修復(fù)。設(shè)置“單用戶”。結(jié)果設(shè)置都產(chǎn)生死鎖，無法運(yùn)行！

設(shè)置單用戶模式后非常難恢復(fù)多用戶模式。似乎不斷有進(jìn)程來運(yùn)行。

干脆把集群還有一個(gè)節(jié)點(diǎn)server（虛擬機(jī)）關(guān)閉了！

進(jìn)來還是一樣的錯(cuò)誤。

再接著不用集群連接。到節(jié)點(diǎn)server運(yùn)行。還是一樣！！

再以專用管理員DAC 啟動(dòng)服務(wù)，看誰還能連接！

進(jìn)來后老提示還有一個(gè)用戶在執(zhí)行，此時(shí)設(shè)置數(shù)據(jù)庫為多用戶模式也不行！

好！

再更改port。重新啟動(dòng)mssql服務(wù)。看誰還連接。結(jié)果沒人搶了！能夠進(jìn)行操作也不會(huì)死鎖，也沒其它人操作，此時(shí)能夠進(jìn)行修復(fù)了！

兩個(gè)較小（60GB和1GB）的數(shù)據(jù)庫沒問題；DBCC checkdb 修復(fù)過程中，有一個(gè)170GB的數(shù)據(jù)庫修復(fù)至tempdb空間不足！

修復(fù)了部分，且停止了。

但非常快，因有些數(shù)據(jù)庫文件都在同一磁盤，磁盤空間不足了！

！使mssql服務(wù)自己主動(dòng)停止！

好吧！

刪除一些數(shù)據(jù)庫dump/log文件。啟動(dòng)服務(wù)分離一些不重要的數(shù)據(jù)庫，把它移走（可能不再用了）。移出共享盤。

什么。權(quán)限不夠。本地管理員都無法移動(dòng)文件。再逐個(gè)將數(shù)據(jù)文件的權(quán)限加入給本地管理員！

空間夠業(yè)務(wù)用了，可是另一個(gè)數(shù)據(jù)庫沒有修復(fù)。。再把暫時(shí)數(shù)據(jù)庫移到本地磁盤，才進(jìn)行DBCC checkdb修復(fù)！

修復(fù)完畢后把 tempdb 改回共享存儲(chǔ)位置。并設(shè)置小一些！

可是，數(shù)據(jù)丟失非常多！。僅僅能備份還原。。

備份文件有專門的存儲(chǔ)，又因昨晚網(wǎng)絡(luò)調(diào)整，無法拷貝！

！

而該數(shù)據(jù)庫在還原前又因損壞無法備份！！

備份為簡單模式，也不能備份日志！。

等待備份恢復(fù)中…………

集群還未恢復(fù)…………

終于還原數(shù)據(jù)庫！

所以平時(shí)在網(wǎng)上看到，誰家數(shù)據(jù)庫宕機(jī)半天都恢復(fù)只是來的云云。出如今自己身上！

相對(duì)好點(diǎn)，數(shù)據(jù)庫僅僅是一個(gè)有問題！

！

內(nèi)部人員使用！但確是比較重要的！

附：

ALTER DATABASE dbname SET EMERGENCY GO ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE GO ALTER DATABASE dbname SET SINGLE_USER GO DBCC CheckDB (dbname , REPAIR_ALLOW_DATA_LOSS) GO --after then: ALTER DATABASE dbname SET MULTI_USER GO

轉(zhuǎn)載于:https://www.cnblogs.com/gavanwanggw/p/7401423.html

總結(jié)

以上是生活随笔為你收集整理的SQLServer Always On FCI 脑裂及可疑状态修复的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。