阻塞可读辅助副本

Question

我们最近从 LogShippingstandby/read-only设置迁移到具有可读辅助设备的多子网 AG 设置。

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

在转移到 AG 的新设置后，我们开始看到我无法理解的阻塞。为什么辅助选择查询会阻止我的可读辅助副本实例中的其他选择查询，即使正在查询的数据库有RCSI enabled？

以下是我捕获的内容

• 主要阻止程序是一些长时间运行的SELECT查询，不会显示任何特定的等待类型，例如 SPID129

• SPID 129阻止会话 ID 45（我确信这不是用户 ID）近 6 小时，这取决于 spid129 并且等待类型是 LCK_M_SCH_M

• SPID 45当这在 6 小时的持续时间内阻止所有其他选择查询时，问题就来了。

我无法理解发生了什么。有人可以帮助我排除故障或寻找正确的方向吗？

Answer 1

无论会话隔离级别或 RCSI 设置如何，针对只读辅助副本的查询都会在快照隔离中隐式运行。这可以避免由于 DML 更改而导致的阻塞。只读查询仍会获取架构稳定性锁，这将阻止重做线程的 DDL 操作，反之亦然。

SPID 129 阻止会话 ID 45（我确信这不是用户 ID）近 6 小时，这取决于 spid129 且等待类型为 LCK_M_SCH_M

在您的情况下，重做线程似乎正在等待架构修改锁，但被长时间运行的查询/事务架构稳定性锁阻止。其他查询又被重做线程阻止。

查看SELECT查询执行计划和事务持续时间以进行修复。