我们已将日志传送设置到备用/只读的辅助 SQL 服务器，以卸载所有 SSRS 报告生成。
这在以下规定的限制范围内工作正常：
- 在事务日志恢复期间踢出用户（我们通过设置多个实例并使用循环调度恢复最近的事务日志来解决这个问题）
- 数据最多在计划的事务日志备份/恢复作业指示的时间范围内过期。
不幸的是，第一次运行任何/所有存储过程时，在事务日志恢复后，完成所需的时间比正常情况要长得多。同一存储过程的所有后续执行都在预期时间内完成。如果我们然后执行另一个存储过程，第一次它很慢，并且所有后续执行都在预期的时间内完成。
作为参考，执行的差异通常是 ~00:02 与第一次运行时 ~01:00 相比。
我认为这与服务器执行统计信息或存储过程参数嗅探/存储执行计划有关。
有没有办法解决这个问题？或者这是事务日志恢复所固有的？
如果它只是第一次执行任何存储过程，我们可以通过在还原时执行任何存储过程来轻松解决这个问题，但它似乎会影响所有存储过程的第一次执行。
我尝试count( * )在 11 个表上运行我用于测试触摸的存储过程。第一次运行时间为 00:32，随后的 count(*) 时间为 00:00。不幸的是，这对存储过程的第一次运行没有任何影响。
is_temporary在执行存储过程之前或之后， 我在主服务器或辅助服务器上都看不到任何统计结果。
我目前正在使用 SQL Server 2012
查询
执行计划：乍一看，查询执行计划似乎有很大不同，但是，在保存执行计划并打开生成的 .sqlplan 文件后，它们完全相同。差异似乎来自我使用的不同版本的 SSMS，主服务器上的 2014 和辅助服务器上的 2018。在辅助节点上查看执行计划时，它会显示在每个节点的百分比和时间成本 ### of ### (##%) 下方——这些数字和实际执行计划都不会在进一步执行时发生变化。
我还包括了客户端统计数据，它们显示几乎完全相同，唯一的区别是主服务器执行服务器回复的等待时间为 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 服务器从备用/只读数据库读取，该数据库由定期事务日志提供并且没有经历这些在第一次执行存储过程时会减慢速度。但是，每次恢复事务日志时，我们的用户都会被踢出，这是上述设置应该解决的问题。
这里有一些可能发生的事情，这里有一个非详尽的列表：
PAGEIOLATCH*如果您检查等待统计信息，您可能会在初始运行期间看到高等待您可以采取一些措施来缓解这种情况
SELECT COUNT(*) FROM dbo.YourTable），为我们提供执行计划的“快”和“慢”示例可以帮助我们准确追踪正在发生的事情。
如果您使用的是 SQL Server 2012 或更高版本，则同步统计信息更新可能会导致延迟。这些“可读的辅助统计信息”在 TempDB 中创建，因为日志传送辅助是只读的。您可以在此处阅读更多相关信息（这篇文章是关于 AG 的，但同样适用于这种情况）：
AlwaysOn：在可读辅助、只读数据库和数据库快照上提供最新统计信息
如果这是导致速度变慢的问题，那么一种解决方案是查找这些统计信息，然后在生产数据库中创建它们，以便它们是最新的并且在恢复后可用。您可以使用以下查询查找临时统计信息：
根据您提供的等待统计信息以及计划相同的事实，这是非常确定的，因为缓冲池已被日志还原清除。
在正常运行中，您将获得 12,768 毫秒（几乎 13 秒）的 IO 等待。
在第一次运行时，您将获得 411,129 毫秒（几乎 7分钟）的 IO 等待。
由于实际过程与查询使用的索引不同，您尝试的
SELECT COUNT(*)方法可能没有帮助。COUNT(*)你有几个选择：SELECT COUNT(*) FROM dbo.YourTable WITH (INDEX (IX_Index_Being_Used_By_Proc)))