dbcc 因無法繼續執行而失敗，因為…總是有每個 db 的狀態更改事件
我得到了一份工作DatabaseIntegrityCheck - USER_DATABASES，失敗並出現以下錯誤：
日期和時間：2018-10-29 02:34:13 命令：DBCC CHECKDB (
$$ one of my databases $$) WITH NO_INFOMSGS, ALL_ERRORMSGS, DATA_PURITY HResult 0x254, Level 21, State 1 無法繼續執行，因為會話處於終止狀態。
我收到一封包含以下錯誤消息的警報電子郵件：
客戶端無法重用 SPID 193 的會話，該會話已為連接池重置。失敗 ID 為 46。此錯誤可能是由較早的操作失敗引起的。在此錯誤消息之前檢查失敗操作的錯誤日誌。
在主伺服器上，我收到以下消息：
可用性組數據庫“所有數據庫”正在將角色從“PRIMARY”更改為“RESOLVING”，因為鏡像會話或可用性組由於角色同步而發生故障轉移。這只是一條資訊性消息。無需使用者操作。
在次級：
可用性組數據庫“每個數據庫”正在將角色從“SECONDARY”更改為“SECONDARY”，因為鏡像會話或可用性組由於角色同步而發生故障轉移。這只是一條資訊性消息。無需使用者操作。
由於我找不到這個錯誤的原因，我已經將它升級給系統管理員朋友，也是因為我懷疑它與網路有關。
問題：由於錯誤日誌中對此一無所知，我還能在哪裡找到有關此問題的任何資訊？
EXEC sp_Blitz @OutputType = ‘markdown’, @CheckServerInfo = 1結果在這裡
我還在
test1可用性組中的一個小型數據庫上執行了以下命令：
DBCC CHECKDB ([test1]) WITH ALL_ERRORMSGS, DATA_PURITY這給了我這裡顯示的結果，重要的是，在這種情況下，它不會導致可用性組中的任何故障轉移或狀態更改。
更新：
昨天我將作業DatabaseIntegrityCheck - USER_DATABASES的時間表從凌晨 2 點更改為凌晨 3 點，它在凌晨 3:43 擾亂了可用性組這似乎是由
dbcc checkdb
我以前經歷過這種行為，其中 AG 出現“曇花一現：”
- 從 PRIMARY 到 RESOLVING 再回到 PRIMARY
- 從中學到中學
我的理解是，在具有少量邏輯處理器 (1-4) 和多個 AG（或具有許多數據庫的 AG）的系統上，其中一些“光點”是不可避免的。尤其是如果伺服器是一個帶有輕微噪音鄰居的虛擬機。
可用性組使用大量工作執行緒基線。您可以在此處詳細了解 AG 的執行緒要求：可用性組的執行緒使用情況
我建議您避免同時執行其他佔用大量 CPU 的計劃任務，以降低發生這些事件的風險。在這種情況下，看起來索引維護與 CHECKDB 同時執行。如果您有足夠大的視窗，請嘗試將它們分散開，以免它們重疊。