阻塞可讀的次要副本

我們最近從 LogShippingstandby/read-only設置遷移到具有可讀輔助節點的 Multi Subnet AG 設置。

通常在舊設置中，我們會選擇執行更長時間的查詢，因為有問題的數據庫超過 20 TB，並且在主數據庫上混合了讀寫工作負載。

轉移到 AG 的新設置後，我們開始看到我無法理解的阻塞。為什麼輔助上的選擇查詢會阻止我可讀輔助副本實例中的其他選擇查詢，即使正在查詢的數據庫有RCSI enabled？

下面是我捕捉到的

• Lead blocker 是一些長時間執行的SELECT查詢，沒有顯示任何特定的等待類型，比如 SPID129
• SPID 129阻止會話 ID 45（我確定這不是使用者 ID）將近 6 小時，這取決於 spid129 並且等待類型是 LCK_M_SCH_M
• 當這SPID 45只是在 6 小時內阻止所有其他選擇查詢時，問題就來了。

我無法理解發生了什麼。有人可以幫我排除故障或尋找正確的方向嗎？

無論會話隔離級別或 RCSI 設置如何，對只讀輔助副本的查詢都會隱式在快照隔離中執行。這避免了由於 DML 更改而導致的阻塞。只讀查詢仍然獲取模式穩定性鎖，這將阻止重做執行緒的 DDL 操作，反之亦然。

SPID 129 阻塞會話 ID 45（我確定這不是使用者 ID）將近 6 個小時，這取決於 spid129，等待類型為 LCK_M_SCH_M

在您的情況下，似乎重做執行緒正在等待模式修改鎖，但被非常長時間執行的查詢/事務模式穩定性鎖阻塞。其他查詢依次被重做執行緒阻塞。

查看SELECT查詢執行計劃和修復事務的持續時間。

引用自：https://dba.stackexchange.com/questions/289363