小编RIa*_*lis的帖子

我们已设置将日志传送到备用/只读的辅助 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 服务器从备用/只读数据库读取，该数据库由定期事务日志提供，并且没有经历这些在第一次执行存储过程时会减慢速度。但是，每次恢复事务日志时，我们的用户都会被启动，这是上述设置应该解决的问题。