Question

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

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

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

我知道存储过程可以进行更多优化，但我不明白为什么SSRS会在执行时从SSMS执行起来只需几秒钟就会超时。

还出现了另一个问题。如果我重新创建存储过程，报表将再次完全呈现。这很好，除非在很短的一段时间后，报告再次开始计时。

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

我更准确地想象它不是报告的根本原因。从SSRS执行时，存储过程导致超时。

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

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

Answer 1

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

如果你要添加很多行列的范围结束（想想关于添加自动编号，或时间戳），直方图专栏将迅速过时。您可以强制立即更新执行UPDATE的T-SQL 统计声明。

Answer 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而不是系统内存中，从而减少了生成报告的速度。

Answer 3

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

Answer 4

基本上我到目前为止所做的就是更多地优化sproc并且它似乎至少暂时解决了这个问题。

我仍然想知道从SSMS调用sproc和SSRS之间有什么区别。

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

4 个答案: