重新啟動後在可讀輔助上的奇怪阻塞
我們正在執行一個 SQL Server 2014 可用性組，其中包含 3 個副本、一個同步（針對此問題的 SQL2）和一個非同步輔助副本。我們還配置了到同步輔助副本的只讀路由。
昨晚 SQL2 從自動 Windows 更新安裝重新啟動。伺服器重新聯機，SQL Server 服務啟動（延遲啟動），數據庫進入恢復狀態。過了一會兒，事件查看器顯示數據庫完整性檢查成功並且數據庫已準備好使用。
數據庫在 SQL Management Studio 中顯示同步狀態。AG 狀態正常，但沒有查詢從數據庫中獲取結果。
查詢被等待類型阻止：HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING。
有時，等待類型更改為“lck_m_s”等待類型，並且被執行數據庫啟動命令的程序的 pid 阻止。我知道這與 SQL Server Enterprise 附帶的快速恢復選項有關，但我不明白為什麼一個簡單的選擇會永遠被阻止。
主要問題是：SQL Server 如何顯示 AG 數據庫是健康的，但實際上並非如此？你認識這個問題嗎？
為了解決這個問題，我們從 AG 中刪除了輔助數據庫並將數據庫重新加入 AG，現在一切都恢復正常了。
聽起來您經歷了 PFE 部落格上這篇文章中描述的行為：
AlwaysOn 可用性組無法查詢可讀輔助副本數據庫：等待類型 HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING
本質上，當輔助節點變為可讀時，主節點上碰巧有一個長時間執行的事務，因此查詢將在輔助節點中被阻止，直到與快照相關的行版本可用。我想刪除和重新添加數據庫與長期執行的事務最終完成是巧合的。
因此，如該部落格文章中所述，這種行為是設計使然。
但是，如果沒有長時間執行的事務，那麼這可能是一個錯誤。該部落格上有一條評論表明其他人遇到了這個問題：
在作業系統修補後重新啟動輔助 SQL Server 後，我遇到了這個問題。在重新啟動之前，在主節點中看不到任何打開的事務。AG 中有兩個數據庫存在此問題。我們已經等待了超過 15 個小時，但仍然可讀的副本無法處理這些數據庫的任何選擇查詢。
如果您能夠重複該行為，最好在回饋站點上報告它和/或在您有支持協議的情況下與 Microsoft 支持聯繫。