恢复日志传送到辅助服务器后，第一个存储过程执行很慢

Question

我们已设置将日志传送到备用/只读的辅助 SQL 服务器，以卸载所有 SSRS 报告生成。
这在以下方面施加的限制内工作正常：

1. 在事务日志恢复期间踢出用户（我们通过设置多个实例并使用循环调度恢复最近的事务日志来解决这个问题）
2. 数据已过时，最多在预定事务日志备份/还原作业指示的时间范围内。

不幸的是，第一次运行任何/所有存储过程，在事务日志恢复后，它需要比正常情况更长的时间来完成。同一存储过程的所有后续执行都在预期时间内完成。如果我们然后执行另一个存储过程，第一次它很慢并且所有后续的执行都在预期的时间内完成。

作为参考，与第一次运行时的 ~01:00 相比，执行差异通常为 ~00:02。

我认为这与服务器执行统计或存储过程参数嗅探/存储执行计划有关。
有没有办法解决这个问题？或者这是事务日志还原所固有的？

如果这只是任何存储过程的第一次执行，我们可以通过在恢复时执行任何存储过程来轻松解决这个问题，但它似乎会影响所有存储过程的第一次执行。

我尝试count( * )在 11 个表上运行我用于测试接触的存储过程。第一次运行时间为 00:32，随后的 count(*) 时间为 00:00。不幸的是，这对存储过程的第一次运行没有任何影响。

is_temporary在执行存储过程之前或之后，我在主服务器或辅助服务器上都看不到任何统计结果。

我目前在SQL Server 2012中


查询Exection计划：
乍一看查询执行计划出现显著不同，但是，在保存的执行计划和打开.sqlplan文件生成它们是完全一样的。差异似乎来自我使用的不同版本的 SSMS，主服务器上的 2014 年和辅助服务器上的 2018 年。查看辅助节点上的执行计划时，它会在每个节点的百分比和 ### (##%) 的时间成本 ### 下方显示 - 这些数字和实际执行计划都不会在进一步执行时发生变化。
我还包括客户端统计数据，它们显示的几乎完全相同，唯一的区别是主服务器执行服务器回复的等待时间为 1.4 秒，而辅助服务器需要 81.3 秒。

正如您预测的那样，我确实从第一次执行中看到了大量 PAGEIOLATCH_SH 锁：

diff after first exec vs diff after second exec
waiting_tasks_count    10903    918  
wait_time_ms          411129  12768  

这种情况的一个奇怪之处是，除了设置的循环多实例部分之外，我们已经让我们的生产 SSRS 服务器从备用/只读数据库读取，该数据库由定期事务日志提供，并且没有经历这些在第一次执行存储过程时会减慢速度。但是，每次恢复事务日志时，我们的用户都会被启动，这是上述设置应该解决的问题。

Answer 1

这里有一些可能的事情，这是一个非详尽的列表：

• 执行计划缓存被日志还原清除，因此第一次需要重新编译计划。如果您的计划有很长的编译时间，这可以解释差异。您没有确切地提及与后续运行相比第一次运行的延迟时间
  • 这似乎是最不可能的 - 您可以在实际执行计划 XML 中看到您的计划编译时间
• 缓冲池在恢复过程中也被清除，因此所有数据必须在第一次执行时从磁盘读取
  • 如果是这种情况，PAGEIOLATCH*如果您检查等待统计信息，您可能会在初始运行期间看到长时间等待

您可以采取一些措施来缓解这种情况

• “预热”缓冲区缓存（通过使用 将重要表中的所有数据读取到内存中SELECT COUNT(*) FROM dbo.YourTable），
• 通过运行所有关键存储过程作为恢复后步骤来“预热”proc 缓存

为我们提供执行计划的“快”和“慢”示例可以帮助我们准确追踪正在发生的事情。

如果您使用的是 SQL Server 2012 或更高版本，则同步统计信息更新可能会导致延迟。这些“可读的辅助统计信息”是在 TempDB 中创建的，因为日志传送辅助是只读的。你可以在这里阅读更多相关信息（这篇文章是关于 AG 的，但同样的事情也适用于这种情况）：

AlwaysOn：提供有关可读辅助、只读数据库和数据库快照的最新统计信息

如果这是导致您速度变慢的问题，那么一种解决方案是找到这些统计信息，然后在生产数据库中创建它们，以便它们在恢复后保持最新并可用。您可以使用此查询查找临时统计信息：

SELECT * FROM sys.stats WHERE is_temporary = 1;

根据您提供的等待统计信息，以及计划相同的事实，这是非常确定的，因为缓冲池被日志还原清除。

在正常运行中，您将获得 12,768 毫秒（近 13 秒）的 IO 等待时间。
在第一次运行时，您将获得 411,129 毫秒（几乎 7分钟）的 IO 等待时间。

SELECT COUNT(*)由于实际过程与COUNT(*)查询使用的索引不同，您尝试的方法可能没有帮助。您在这里有几个选择：

1. 浏览每个执行计划并记下正在使用的索引，然后将这些索引作为恢复后步骤拉入内存 - 这次使用索引提示 ( SELECT COUNT(*) FROM dbo.YourTable WITH (INDEX (IX_Index_Being_Used_By_Proc)))
2. 完成编写过程脚本以运行每个过程作为恢复后步骤的过程（这似乎比选项 1 容易一些）
3. 调整查询，以便它们不需要进行如此多的读取（不确定这是否可行）
4. 加速 I/O 子系统 - 获得更快的磁盘、本地 SSD、更多到 SAN 的通道等（这可能是最困难和最昂贵的选择