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

发布于 2024-07-08 10:19:58 字数 584 浏览 6 评论 0原文

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

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

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

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

另外一个问题也浮出水面。如果我重新创建存储过程，报告将再次开始完美呈现。这很好，只是在很短的时间之后，报告再次开始超时。

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

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

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

该问题似乎也只发生在我们的生产环境中。我们的测试和开发平台似乎没有出现同样的问题。尽管开发和测试没有与生产相同数量的记录。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

香草可樂 2024-07-15 10:19:58

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

如果您要在
列范围的末尾（认为
关于添加自动编号，或者
时间戳），其直方图
专栏很快就会过时。
您可以强制立即更新
通过执行 UPDATE 的 T-SQL
统计报表。

回复收藏 0 原文

挽你眉间 2024-07-15 10:19:58

我也遇到过这样的问题：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

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

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

I have also had this issue where the SPROC takes seconds to run yet SSRS simply times out.

I have found from my own experience that there are a couple of different methods to overcome this issue.

Is parameter sniffing! When your stored procedure is executed from SSRS it will "sniff" out your parameters to see how your SPROC is using them. SQL Server will then produce an execution plan based on its findings. This is good the first time you execute your SPROC, but you don't want it to be doing this every time you run your report. So I declare a new set of variables at the top of my SPROC's which simply store the parameters passed in the query and use these new parameters throughout the query.

Example:

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

...this means that when your SPORC is executed by SSRS it is only looking at the first few rows in your query for the passed parameters rather than the whole of your query. Which cuts down execution time considerably in SSRS.

If your SPROC has a lot of temp tables that are declared as variables (DECLARE @MyTable AS TABLE), these are really intensive on the server (In terms of memory) when generating reports. By using hash temp tables (SELECT MyCol1, MyCol2 INTO #MyTable) instead, SQL Server will store your temp tables in TempDB on the server rather than in system memeory, making the report generation less intensive.

回复收藏 0 原文