节点故障转移后使 SQL 联机的时间更长

Question

在为 SQL 服务器进行常规操作系统修补后，我们遇到了一个奇怪的问题。

根据最佳实践，我们在被动上应用补丁并进行节点故障转移以使当前被动、主动，反之亦然以完成修补。

通常节点故障转移是无缝的并且在一分钟内完成。但是最近我们遇到了一个问题，在节点故障转移后需要 4 分钟才能使 SQL 联机：

我正在检查日志和事件，但找不到原因：以下是迄今为止的调查结果：

注意：SQL 服务器在 VM 上运行

1. SQL 服务器活动没有增加
2. 数据库是数据库镜像的一部分
3. 在此期间内运行时间更长的用户连接或用户查询不会增加
4. 所有数据库的 VLF 低于 500
5. 无 CPU/内存压力和 LPIM 已启用。
6. 在故障转移期间似乎终止长时间运行的进程是 EXEC sp_server_diagnostics 20 running for last 86745234 secs

请协助我还应该检查什么才能找到根本原因？

编辑 - 我尝试分析集群日志，可以看到 sql 离线已启动，但我不确定它在内部花了至少 4 分钟的时间来实际关闭 sql 并将其恢复。4 分钟后，sql 错误日志将数据库的所有条目都调高了大约 10 秒。所以看起来 DB 可能没有参与这里来减慢进程。

编辑 - 当前检查时的一些 VLF 信息

Answer 1

您的问题很可能是由于数据库进行恢复以重做或撤消尚未强化到数据文件的事务引起的。

一起避免恢复

在对 FCI（尤其是具有大量内存的 FCI）进行计划的服务器重启或故障转移之前，我喜欢在每个数据库上运行一个。这最大限度地减少了干净关闭所有数据库的时间，并且（当数据库没有干净地关闭时）最大限度地减少重新启动时的崩溃恢复时间。CHECKPOINT

我用sp_ineachdb从第一响应者工具包来做到这一点：

EXEC DBA.dbo.sp_ineachdb 'CHECKPOINT;`;

如果你讨厌让你的生活更轻松的免费代码，你可以用动态 SQL 做一些事情：

DECLARE @sql nvarchar(max) = N'';

SELECT @sql += N'CHECKPOINT ' + QUOTENAME(name) + '; '
FROM sys.databases;

EXEC sys.sp_executesql @stmt = @sql;

但是通过减少工作量来加快恢复速度

当然，正如Erik、Darling在评论中提到的那样，请确保您的 VLF 井井有条且大小合适。在崩溃恢复期间扫描这些 VLF 会导致您所看到的所有痛苦。对于计划内维护，您可以CHECKPOINT最小化或消除崩溃恢复。但是，如果您有……呃……意外的崩溃和故障转移，那么崩溃恢复仍然会发生，而且您对此无能为力。

不那么直接

我在间接检查点方面也很幸运。我们已在整个环境中推广此功能，并取得了巨大成功。

并游说升级的权力

SQL Server 2019 包含一项名为Accelerated Database Recovery的功能，可以加快恢复过程，尤其是在存在长时间运行的大型事务时。ADR 不仅用于崩溃后的恢复，还有助于其他需要恢复事务日志的场景——包括可用性组二级重做和故障转移集群实例故障转移。