为什么SSRS基于的存储过程在几秒钟内返回结果时会报告超时？答案

【问题标题】：Why does a SSRS report time out when the Stored Procedure it is based on returns results within a few seconds?为什么SSRS基于的存储过程在几秒钟内返回结果时会报告超时？
【发布时间】：2010-09-19 05:17:40
【问题描述】：

我有一个呈现从存储过程返回的数据的报表。使用分析器，我可以捕获报告服务对存储过程的调用。

报告失败，说明报告超时，但我可以从 SSMS 执行存储过程，它会在五到六秒内返回数据。

请注意，在示例测试运行中，只有两行返回到报告以进行呈现，尽管在存储过程中它可能已经处理了数千甚至数百万条记录，以便整理传递回报告服务的结果。

我知道存储过程可以进一步优化，但我不明白为什么 SSRS 会超时，而从 SSMS 执行似乎只需要几秒钟。

另外一个问题也浮出水面。如果我重新创建存储过程，报表将再次完美呈现。没关系，除非在很短的一段时间后，报告再次开始超时。

超时的返回似乎与正在运行报告的主表中添加新数据有关。在我正在测试的示例中，仅插入 100 条新记录就足以搞砸报告。

我更正确地认为，根本原因不是报告。从 SSRS 执行时，是存储过程导致超时。

一旦再次超时，我目前最好的解决方法是重新创建存储过程。这似乎不是一个理想的解决方案。

这个问题似乎也只发生在我们的生产环境中。我们的测试和开发平台似乎没有出现同样的问题。虽然 dev 和 test 的记录量不及生产。

【问题讨论】：

标签： sql-server stored-procedures reporting-services timeout

【解决方案1】：

正如您所描述的，问题似乎来自存储过程中某些部分的执行计划的变化。查看使用的表保留了哪些统计信息以及添加新行对它们有何影响。

如果您在列范围的结尾（想想关于添加自动编号，或时间戳），其直方图列将很快过时。您可以强制立即更新 T-SQL 通过执行 UPDATE STATISTICS 语句。

【讨论】：

【解决方案2】：

我也遇到过这个问题，即 SPROC 需要几秒钟才能运行，而 SSRS 只是超时。

根据我自己的经验，我发现有几种不同的方法可以解决这个问题。

是参数嗅探！当您的存储过程从 SSRS 执行时，它会“嗅出”您的参数以查看您的 SPROC 是如何使用它们的。 SQL Server 随后将根据其发现生成一个执行计划。这在您第一次执行 SPROC 时很好，但您不希望它在每次运行报表时都这样做。因此，我在 SPROC 的顶部声明了一组新变量，它们仅存储在查询中传递的参数并在整个查询中使用这些新参数。

例子：

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

...这意味着当您的 SPORC 由 SSRS 执行时，它只会查看查询中的前几行以获取传递的参数，而不是整个查询。这大大减少了 SSRS 中的执行时间。

如果您的 SPROC 有很多被声明为变量的临时表 (DECLARE @MyTable AS TABLE)，那么在生成报告时，这些临时表在服务器上（就内存而言）是非常密集的。通过改用哈希临时表 (SELECT MyCol1, MyCol2 INTO #MyTable)，SQL Server 会将您的临时表存储在服务器上的 TempDB 中，而不是系统内存中，从而减少生成报告的密集度。

【讨论】：

很好看。如果可以的话，我会给你10分。这立即修复了我的 SSRS 存储过程！

【解决方案3】：

有时在存储过程的 CREATE 语句中添加 WITH RECOMPILE 选项会有所帮助。这在过程探索的记录数量以原始执行计划不是最优的方式发生变化的情况下非常有效。

【讨论】：

【解决方案4】：

到目前为止，基本上我所做的只是进一步优化存储过程，它似乎至少暂时解决了问题。

我还是想知道从 SSMS 和 SSRS 调用存储过程有什么区别。

【讨论】：