FCI 雙節(jié)點集群，因為晚上集群節(jié)點間的網絡中斷過。兩個節(jié)點都覺得還有一個節(jié)點宕機，在各節(jié)點的集群管理中都看到對方已宕機。

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

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

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

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

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

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

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

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

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

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

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 錯誤: 3624，嚴重性: 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 錯誤: 3314，嚴重性: 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 錯誤: 9004，嚴重性: 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 錯誤: 9004，嚴重性: 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 錯誤: 9004，嚴重性: 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 錯誤: 3314，嚴重性: 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.

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

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

How to troubleshoot Error 9004 in SQL Server

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

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

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

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

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

重新啟動server比較好，不用逐個轉移，使其自己主動全部資源轉移。

重新啟動之后！

。

msdb 正常了！！

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

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

設置單用戶模式后非常難恢復多用戶模式。似乎不斷有進程來運行。

干脆把集群還有一個節(jié)點server（虛擬機）關閉了！

進來還是一樣的錯誤。

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

再以專用管理員DAC 啟動服務，看誰還能連接！

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

好！

再更改port。重新啟動mssql服務。看誰還連接。結果沒人搶了！能夠進行操作也不會死鎖，也沒其它人操作，此時能夠進行修復了！

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

修復了部分，且停止了。

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

！使mssql服務自己主動停止！

好吧！

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

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

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

修復完畢后把 tempdb 改回共享存儲位置。并設置小一些！

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

備份文件有專門的存儲，又因昨晚網絡調整，無法拷貝！

！

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

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

等待備份恢復中…………

集群還未恢復…………

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

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

相對好點，數(shù)據(jù)庫僅僅是一個有問題！

！

內部人員使用！但確是比較重要的！

附：

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

轉載于:https://www.cnblogs.com/gavanwanggw/p/7401423.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。