SQLServer Always On FCI 腦裂及可疑狀態修復

FCI 雙節點集羣，由於晚上集羣節點間的網絡中斷過。兩個節點都以爲還有一個節點宕機，在各節點的集羣管理中都看到對方已宕機。

鏈接到集羣IP。提示 msdb 數據庫有問題：

發現MSDB數據庫 「可疑」

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

SQL Server 斷言: 文件: <xdes.cpp>，行=3785 失敗的斷言 = 'curr->GetXdesId () == m_xdesId'。
此錯誤可能與時間有關。假設又一次執行該語句後錯誤仍然存在，請使用 DBCC CHECKDB 來檢查數據庫的結構是否完整，或又一次啓動server以確保內存中的數據結構未破壞。

在數據庫 'msdb' 中撤消日誌記錄下的操做時。在日誌記錄 ID (106502:3622:2) 處出錯。一般。這一特定故障曾經在 Windows 事件日誌服務中會記錄爲錯誤。請利用備份還原數據庫或文件，或者修復該數據庫。

處理數據庫 'msdb' 的日誌時出錯。假設可能，請從備份還原。假設沒有可用備份，可能需要又一次生成日誌。


由於在例程 'XdesRMReadWrite::RollbackToLsn' 中錯誤發生 3314。數據庫 msdb 已關閉。在與該數據庫的所有鏈接都停止後，將嘗試又一次啓動非快照數據庫。

在數據庫 'msdb' 中撤消日誌記錄下的操做時，在日誌記錄 ID (106502:3614:1) 處出錯。一般，這一特定故障曾經在 Windows 事件日誌服務中會記錄爲錯誤。
請利用備份還原數據庫或文件，或者修復該數據庫。


傳遞給數據庫 'msdb' 中的日誌掃描操做的日誌掃描號 (106502:3144:155) 無效。此錯誤可能指示數據損壞，或者日誌文件(.ldf)與數據文件(.mdf)不匹配。假設此錯誤是在複製期間出現的。請又一次建立公佈。不然。假設該問題致使啓動期間出錯。請從備份還原。

恢復期間出錯，致使數據庫「msdb」(4:0)沒法又一次啓動。請診斷並糾正這些恢復錯誤，或者從已知的正確備份中還原。假設沒法更正錯誤，或者爲意外錯誤，請與技術支持人員聯繫。

可疑推斷 msdb 數據庫日誌有損壞。

sql server 還有本身主動監控的一些跟蹤。主要系統錯誤和鏈接錯誤等其它重要性錯誤信息，查看例如如下：

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，狀態: 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，狀態: 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，狀態: 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。狀態: 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，狀態: 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，狀態: 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.

主要幾個狀態：362四、331四、900四、3414
基本緣由例如如下：

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

How to troubleshoot Error 9004 in SQL Server

由於msdb日誌備份引發的（發現msdb數據文件有 60+GB！）

現在集羣有問題了，相互佔用資源。心跳沒起做用。鏈接數據庫內部查看節點能正常鏈接到當中一個。

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

更重要的是：因爲存儲是共享的。系統數據庫和用戶數據庫都共享！

兩個節點用共享存儲，按理說數據是一致的。爲了使集羣能恢復正常狀態，打算轉移集羣。

從新啓動server比較好，不用逐個轉移，使其本身主動所有資源轉移。

從新啓動以後！

。

msdb 正常了！！

但是有 3 個用戶數據庫出現了 「可疑」。！

沒辦法。出現了就僅僅能修復吧。。設置 「緊急」 模式修復。設置「單用戶」。結果設置都產生死鎖，沒法運行！

設置單用戶模式後很是難恢復多用戶模式。彷佛不斷有進程來運行。

乾脆把集羣還有一個節點server（虛擬機）關閉了！

進來仍是同樣的錯誤。

再接着不用集羣鏈接。到節點server運行。仍是同樣！！

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

進來後老提示還有一個用戶在執行，此時設置數據庫爲多用戶模式也不行！

好！

再更改port。從新啓動mssql服務。看誰還鏈接。結果沒人搶了！可以進行操做也不會死鎖，也沒其它人操做，此時可以進行修復了！

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

修復了部分，且中止了。

但很是快，因有些數據庫文件都在同一磁盤，磁盤空間不足了！

！使mssql服務本身主動中止！

好吧！

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

什麼。權限不夠。本地管理員都沒法移動文件。再逐個將數據文件的權限加入給本地管理員！

空間夠業務用了，但是另外一個數據庫沒有修復。。再把暫時數據庫移到本地磁盤，才進行DBCC checkdb修復！

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

但是，數據丟失很是多！。僅僅能備份還原。。

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

！

而該數據庫在還原前又因損壞沒法備份！！

備份爲簡單模式，也不能備份日誌！。

等待備份恢復中…………

集羣還未恢復…………

終於還原數據庫！

因此平時在網上看到，誰家數據庫宕機半天都恢復只是來的云云。出現在本身身上！

相對好點，數據庫僅僅是一個有問題！

！

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

附：

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