阻塞可读的二级副本

Question

最近，我们从LogShipping standby/read-only安装程序迁移到多子网AG安装程序，具有可读的二级代码。

通常，在旧的设置中，我们可以选择运行时间更长的查询，因为所讨论的数据库超过20 TB，并且主数据库上有读写工作负载的混合。

在移动到AG的新设置后，我们开始看到阻塞，我无法理解。为什么二级上的select查询会阻塞我可读的二级副本实例中的其他select查询，即使被查询的数据库有RCSI enabled？

下面是我捕捉到的

• 铅阻止程序是一些长时间运行的SELECT查询，没有显示任何特定的等待类型，比如SPID 129。
• SPID 129阻塞会话ID 45 (我肯定这不是用户id)将近6个小时，这依赖于spid129，等待类型是LCK_M_SCH_M
• 当这个SPID 45仅在6小时内阻塞所有其他select查询时，问题就出现了。

我无法理解正在发生的事情。有人能帮我排除故障或朝正确的方向看吗？

Answer 1

对只读辅助副本的查询隐式地运行在快照隔离状态下，而不考虑会话隔离级别或RCSI设置。这避免了由于DML更改而造成的阻塞。只读查询仍然获得模式稳定性锁，这将通过重做线程阻止DDL操作，而visa则相反。

SPID 129阻塞会话ID 45 (我肯定这不是用户id)，时间将近6个小时，它依赖于spid129，等待类型为LCK_M_SCH_M

在您的示例中，重做线程似乎在等待模式修改锁，但是被一个运行时间很长的查询/事务模式稳定性锁所阻止。其他查询则被重做线程阻塞。

查看SELECT查询执行计划和用于补救的事务的持续时间。

Answer 2

我发现了来自ALTER重建活动的相同问题。我解决了把这个活动移到另一个时间窗口的问题。