RIanGillis's questions

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

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

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

作为参考，执行的差异通常是 ~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 服务器从备用/只读数据库读取，该数据库由定期事务日志提供并且没有经历这些在第一次执行存储过程时会减慢速度。但是，每次恢复事务日志时，我们的用户都会被踢出，这是上述设置应该解决的问题。

我正在将两个数据库的备用/只读模式下的事务日志传送设置到多个实例。

在将事务日志备份并还原到其单独的实例（每个实例上每个数据库的一个副本）后，当我执行以下操作时，其中一个数据库没有问题：

ALTER DATABASE [dbname] SET SINGLE USER WITH ROLLBACK IMMEDIATE;
ALTER DATABASE [dbname] SET MULTI_USER;

另一个抛出错误：

Failed to update database "other_dbname" because the database is read-only.

我看不出两者有什么区别。我检查了属性，所有选项都相同。在选项选项卡中，会引发错误的数据库将兼容性级别设置为 SQL Server 2012，而允许我更改的数据库将该值设置为 SQL Server 2014，但将它们都更改为 2014 并不能解决问题。

我完全不知道问题可能是什么，或者我可以研究什么会为我指明正确的方向。

编辑：上述命令在链接服务器上执行，如果这可能与它有关。用户相同，权限相同，我能够在第一个数据库上执行命令，无论它们是通过 SSMS 还是通过作业执行，它们总是在第二个数据库上失败。

选项：