SQL Server 修补后的故障转移时间

Question

• 我们有两个节点 Windows Server 集群，每个节点上安装了 SQL Server（2019 标准版）集群实例
• 有 500 个活动数据库
• 没有配置任何可用性组或任何其他 HA 解决方案
• 所有数据库均处于简单恢复模式
• VLF 数量和尺寸都不是很大
• 两个节点都是虚拟化的 Windows Server 2019，具有 64 GB 内存和 16 核。

修补被动节点并重新启动后，我们尝试故障转移到该节点。但令人惊讶的是，启动 SQL Server 服务大约需要 10 分钟，该服务挂起在更改挂起状态。在不打补丁的常规情况下，大约需要 10 秒。我从微软文档中得知，停机时间取决于故障转移时间和数据库升级脚本执行的总时间：

这一过程导致整个故障转移集群升级期间的停机时间仅限于一次故障转移时间和数据库升级脚本执行时间。

在我看来，这个停机时间似乎很长，只是在寻找以某种方式减少它的方法。如果您有任何建议，我将非常乐意倾听。

Answer 1

修补被动节点并重新启动后，我们尝试故障转移到该节点。但令人惊讶的是，启动 SQL Server 服务大约需要 10 分钟，该服务挂起在更改挂起状态。

修补后，正如您精明地指出的那样，升级脚本仍然需要针对每个数据库运行。目前，具有 16 核的服务器上有 500 个数据库，这导致最大工作线程的值为 704。虽然我不一定相信您遇到了 MWT 问题（尽管错误日志会告诉您，但我们没有错误日志），但我确实相信您在太少的系统上进行了太多的工作。这不足以使系统瘫痪或崩溃，但足以使其需要时间来完成处理项目。这也是一个虚拟机，我们不知道主机或它在资源公平性方面可能会或可能不会做什么。

在我看来，这个停机时间似乎很长，只是在寻找以某种方式减少它的方法。如果您有任何建议，我将非常乐意倾听。

由于我没有错误日志或性能计数器的副本，因此很难准确或准确，因此上述内容基于我们当前拥有的数据。这里可能涉及许多其他因素，包括磁盘访问时间、服务器上的其他项目、可用和最大服务器内存等。

没有单一的旋钮或项目，除非您有数据显示 X 很慢或 Y 花了很长时间 - 那么您可以对此进行磨练。目前，系统上似乎确实有许多可用 CPU 数量的数据库。

如果您有类似的设置测试系统，则可以设置性能捕获并运行修补过程 -> 故障转移，以获取更多信息。

来自评论：

除非它自 2016 年以来发生了变化（据我所知，它没有发生变化），否则升级脚本会串行运行数据库（因此 MWT 不会发挥作用）[...]

这是不正确的，至少自 2005 年以来，情况并非如此。数据库将并行启动并升级，如下所示，这是我在创建 500 个虚拟数据库后运行的 CU 更新的摘录。

2023-04-25 05:44:27.98 spid20s     Starting up database 'BreakMeDB1'.
2023-04-25 05:44:27.98 spid21s     Starting up database 'BreakMeDB2'.
2023-04-25 05:44:27.98 spid22s     Starting up database 'BreakMeDB3'.
2023-04-25 05:44:27.99 spid31s     Starting up database 'BreakMeDB12'.
2023-04-25 05:44:27.99 spid33s     Starting up database 'BreakMeDB14'.
2023-04-25 05:44:27.99 spid32s     Starting up database 'BreakMeDB13'.
2023-04-25 05:44:27.99 spid27s     Starting up database 'BreakMeDB8'.
2023-04-25 05:44:27.99 spid29s     Starting up database 'BreakMeDB10'.
2023-04-25 05:44:27.99 spid34s     Starting up database 'BreakMeDB15'.
2023-04-25 05:44:27.99 spid28s     Starting up database 'BreakMeDB9'.
2023-04-25 05:44:27.99 spid23s     Starting up database 'BreakMeDB4'.
2023-04-25 05:44:27.99 spid24s     Starting up database 'BreakMeDB5'.
2023-04-25 05:44:27.99 spid30s     Starting up database 'BreakMeDB11'.
2023-04-25 05:44:27.99 spid25s     Starting up database 'BreakMeDB6'.
2023-04-25 05:44:27.99 spid26s     Starting up database 'BreakMeDB7'.