重新启动后在可读二级上出现奇怪的阻塞

Question

我们正在运行一个带有 3 个副本的 SQL Server 2014 可用性组，一个同步（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 中，现在一切又恢复正常了。

Answer 1

听起来您经历过 PFE 博客上这篇文章中描述的行为：

本质上，当辅助节点变得可读时，主节点上恰好有一个长时间运行的事务，因此查询将在辅助节点中被阻塞，直到与快照相关的行版本可用。我想删除和重新添加数据库与长期运行的事务最终完成是巧合的。

因此，如该博客文章中所述，这种行为是设计使然。

但是，如果没有长时间运行的事务，那么这可能是一个错误。该博客上有一条评论表明其他人也遇到过这个问题：

在操作系统修补后重新启动辅助 SQL Server 后，我面临这个问题。在重新启动之前，在主数据库中看不到任何打开的事务。AG 中有两个数据库存在此问题。我们已经等待了 15 多个小时，但可读副本仍然无法处理这些数据库的任何选择查询。

如果您能够重复该行为，最好在反馈站点上报告该行为和/或在您有支持协议的情况下与 Microsoft 支持联系。