主页 / dba / 问题 / 289363
Accepted
Newbie-DBA
Asked: 2021-04-07 06:13:26 +0800 CST

阻塞可读的次要副本

  • 772

我们最近从 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 小时内阻止所有其他选择查询时，问题就来了。

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

sql-server availability-groups

2 个回答

  1. Best Answer

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

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

    在您的情况下，似乎重做线程正在等待模式修改锁，但被非常长时间运行的查询/事务模式稳定性锁阻塞。其他查询依次被重做线程阻塞。

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

    • 4

  2. 我发现了来自 ALTER INDEX REBUILD 活动的相同问题。我解决了在另一个时间窗口中移动此活动的问题。

    • 1

相关问题