SQLServer Always On FCI 叢集節點同時佔用資源及可疑狀態修複

標籤：無法   日誌記錄   enter   data   nod   tac   監控   for   iat   

FCI 雙節點叢集，由於晚上叢集節點間的網路中斷過，兩個節點都認為另一個節點宕機，在各節點的叢集管理中都看到對方已宕機。

串連到叢集IP，提示 msdb 資料庫有問題：

發現MSDB資料庫 “可疑”

msdb 損壞了，mssql 錯誤記錄檔和代理日誌也無就法查詢，從windows查看到資訊如下：

SQL Server 斷言: 檔案: <xdes.cpp>，行=3785 失敗的斷言 = ‘curr->GetXdesId () == m_xdesId‘。此錯誤可能與時間有關。如果重新運行該語句後錯誤仍然存在，請使用 DBCC CHECKDB 來檢查資料庫的結構是否完整，或重新啟動伺服器以確保記憶體中的資料結構未破壞。在資料庫 ‘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 = 1SELECT * 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.

主要幾個狀態：3624、3314、9004、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_nodesSELECT * FROM fn_virtualservernodes();

更重要的是：因為儲存是共用的，系統資料庫和使用者資料庫都共用！

兩個節點用共用儲存，按理說資料是一致的。為了使叢集能恢複正常狀態，打算轉移叢集。重啟伺服器比較好，不用逐個轉移，使其自動所有資源轉移。

重啟之後！！

msdb 正常了！！

但是有 3 個使用者資料庫出現了 “可疑”！！

沒辦法，出現了就只能修複吧！！設定 “緊急” 模式修複，設定“單使用者”，結果設定都產生死結，無法執行！

設定單一使用者模式後很難恢複多使用者模式，似乎不斷有進程來執行！

乾脆把叢集另一個節點伺服器（虛擬機器）關閉了！進來還是一樣的錯誤。

再接著不用叢集串連，到節點伺服器執行，還是一樣！！

再以專用管理員DAC 啟動服務，看誰還能串連！進來後老提示另一個使用者在運行，此時設定資料庫為多使用者模式也不行！

好！再更改連接埠，重啟mssql服務，看誰還串連！結果沒人搶了！可疑進行操作也不會死結，也沒其他人操作，此時可以進行修複了！

兩個較小（60GB和1GB）的資料庫沒問題；DBCC checkdb 修複過程中，有一個170GB的資料庫修複至tempdb空間不足！修複了部分，且停止了。

但很快，因有些資料庫檔案都在同一磁碟，磁碟空間不足了！！使mssql服務自動停止！

好吧！刪除一些資料庫dump/log檔案，啟動服務分離一些不重要的資料庫，把它移走（可能不再用了），移出共用盤。

什麼！許可權不夠，本地管理員都無法移動檔案！再逐個將資料檔案的許可權添加給本地管理員！

空間夠業務用了，但是還有一個資料庫沒有修複！！再把臨時資料庫移到本地磁碟，才進行DBCC checkdb修複！

修複完成後把 tempdb 改回共用儲存位置，並設定小一些！

此叢集節點上修複完成！！！

但是，資料可能有丟失，叢集還未敢恢複。

ALTER DATABASE dbname SET EMERGENCY GOALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATEGOALTER DATABASE dbname SET SINGLE_USER GODBCC CheckDB (dbname , REPAIR_ALLOW_DATA_LOSS) GO--after then:ALTER DATABASE dbname SET MULTI_USER GO

SQLServer Always On FCI 叢集節點同時佔用資源及可疑狀態修複