0

我有一个 SSRS 报告，它TimeDataRetrieval（根据数据库中的ExecutionLog3表ReportingServices）在一夜之间增加了 60 秒，我不知道为什么。

该报告有两个参数并包含一个数据集，该数据集将其中一个报告参数传递给 SQL 存储过程。我可以在 SSMS 中独立运行存储过程，它可以在几秒钟内完成，与之前的报告性能一致。

我已经在网上阅读了许多关于参数嗅探如何影响 SQL 为存储过程构建的执行计划的线程和文章，当它从 SSRS 报告调用时与直接运行时相比，但我尝试将内部变量添加到存储的过程，将传入的参数值分配给该变量并在存储过程中的查询中使用该变量而不是参数，但这对问题没有任何影响。我什至还尝试添加OPTION(RECOMPILE)到存储过程，但这同样没有影响。

在我们将 Dynamics CRM 2015 系统（其数据库与此 SSRS 实例驻留在同一个 SQL Server 上 - 我知道这可能是个坏主意）升级到 Dynamics 365 后，问题就开始出现了，所以我想知道这是否有某种意义处理它，但我不知道如何解决这个问题，所以任何建议都将受到欢迎！

4

1 回答 1

0

这个 SP 运行的表的大小是否稳定增长？有时，您会受到“阈值”影响，突然行数会导致性能问题。我建议您重建所有正在使用的表的统计信息并添加OPTION(RECOMPILE)并重新测试。

此外，当尝试在 SSMS 中重新创建时，您必须确保还包括所有SET选项。您应该使用分析器捕获 SQL 并准确使用它，包括它之前的所有四个或五个设置选项（即 SET ARITHABORT）

您可能会发现您可以在 SSMS 中重现，在这种情况下，这肯定是参数嗅探问题。（尽管重新编译通常会解决这个问题）

于 2017-10-25T14:11:37.873 回答