Question

我创建了一个SSRS报告，用于使用存储过程检索55000条记录。什么时候从存储过程执行它只需要3秒钟，但从SSRS报告执行时需要超过一分钟。我该如何解决这个问题？

Answer 1

额外的时间可能是由于Reporting Services除了查询数据外还呈现报告。例如，如果您为报告返回了55,000行，那么报表服务器必须对这些行进行分组，排序和/或过滤以呈现报表，这可能需要额外的时间。

我将查看数据在报表中进行分组和过滤的方式，然后查看存储过程以查看是否可以将某些处理卸载到SQL代码中，可能使用某些参数。尝试并且旨在将返回到报表的行数减少到呈现报表所需的最小值，并且最好避免在报表本身中进行分组和过滤。

Answer 2

由于我的SP中的参数嗅探，我遇到了这样的问题。在SQL Management Studio中，当我运行我的SP时，我使用新的执行计划重新创建它（并且调用速度非常快），但我的报告使用旧的错误计划（对于另一个参数序列）并且加载时间比在SQL MS中长得多。

Answer 3

在ReportServerDB中，您将找到一个名为ExecutionLog的表。您必须查找报告的目录ID并检查最新的执行实例。这可以告诉你时间的分解 - 数据检索，处理，渲染等等。

Answer 4

使用SSRS Performance Dashboard报告调试您的问题。

Answer 5

古老的问题，但因为这样的事情有点复发，我的“快速而肮脏”的改进SSRS的解决方案，在大型企业环境中完美运行（我每天渲染的报告最多可达100.000+行）是正确的设置页面的 InteractiveSize （例如，将其设置为A4大小-21厘米）。当InteractiveSize设置为0时，所有结果将呈现为单页，这实际上会破坏SSRS的性能。在这种情况下，数据库上可能需要几秒钟的查询可能会永远呈现（或导致内存不足异常，除非您的SSRS服务器上有大量冗余H / W）。因此，如果查询/ SP在直接调用上执行得相当快并且检索大量行，请设置InteractiveSize，您不需要为其他更复杂的解决方案而烦恼。

Answer 6

显然，使报告正常运行（即采用相同的时间量来选择数据作为SSMS）将是更可取的，但作为一种解决方法，您的报告是否支持执行快照（即没有存储参数或参数默认值）在报告中）？

这将允许预先检索和存储数据的计划快照，这意味着SSRS只需在用户打开报告时处理和呈现报告。应该将等待时间减少到几秒钟（取决于报告所需的处理.YMMV，测试是否获得性能改进）。

转到报告管理器中的报告属性选项卡，选择执行，更改为从报告执行快照渲染此报告，指定您的计划。

Answer 7

加速SSRS报告的主要解决方案是缓存报告。如果这样做（例如我在上午7:30预加载缓存）或缓存报告命中，那么会发现加载速度大幅上升。

请注意我每天和专业这样做，而不是简单地在SSRS上打造诗意

SSRS中的缓存 http://msdn.microsoft.com/en-us/library/ms155927.aspx

预加载缓存 http://msdn.microsoft.com/en-us/library/ms155876.aspx

如果您不喜欢初始报告需要很长时间且数据是静态的，即每日总帐等，这意味着数据在当天相对静态，可能会延长缓存寿命。

最后，您也可以选择业务经理通过电子邮件订阅接收这些报告，这会向他们发送一个他们可能会发现的Excel报告的时间点更系统化。

您还可以使用SSRS中的参数，以便用户轻松解析和更快的查询。在查询构建器中，在希望参数化的“过滤器”列下键入IN（@SSN），然后您将在BIDS GUI左上角的数据源正上方的参数文件夹中找到它。 [如果在SSRS中没有看到数据源部分，请按CTRL + ALT + D.

在此处查看几乎相同的问题：Performance Issuses with SSRS

Answer 8

为改善报告的绩效，可以采取以下措施： 1.在报表管理器上启用缓存，并设置刷新缓存的时间段。 2.对在报表中用作源的所有后端数据库表应用索引，尽管存储过程在呈现数据时花费的时间非常少，但仍然应用索引可以进一步提高后端级别的性能。 3.使用共享数据集而不是在报表中使用嵌入数据集，并对所有这些数据集应用缓存。 4.如果可能，将参数设置为加载默认值。 5.尝试减少存储过程选择的数据，例如如果报告包含无用的历史数据，则可以添加过滤器以排除该数据。

Answer 9

我遇到了同样的问题。查询在SQL中运行得很好但在SSRS中的任何内容都很慢。您在数据集中使用SSRS参数吗？我发现，如果您在某些查询中直接使用报表参数，则会有很大的性能损失。

相反，如果您有一个名为@reportParam的报表参数，请在数据集中执行以下操作：

declare @reportParamLocal int
set @reportParamLocal = @reportParam

select * from Table A where A.field = @reportParam

有点奇怪。我不太清楚它为什么会起作用，但它对我有用。

Answer 10

您可能想要了解的一件事是，报表中的元素是否会降低执行速度。

例如，我在dateTimes之间转换时发现了大量的执行时间差异。报表上的任何元素都使用CDate函数吗？如果是这样，您可能需要考虑在sql级别进行格式化。

一般来说，转化会导致大幅减速，因此请花点时间查看数据集，看看可能出现的问题。

Answer 11

这是上述答案的混合，但尽可能以最简单和最完整的格式从存储过程中获取数据。我在服务器上进行所有排序，分组和过滤。服务器是为此而构建的，我只是让报告服务进行漂亮的显示工作。

Answer 12

我有同样的问题......确实是渲染时间，但更具体地说，这是因为SORT在SSRS中。尝试将您的排序移动到存储过程并从SSRS报告中删除任何SORT。在55K行上，这将显着改善它。

Answer 13

继@ RomanBadiornyi的回答之后，尝试添加

OPTION (RECOMPILE)

到存储过程中主查询的末尾。

这将确保每次重新编译查询以查找不同的参数，以防不同的参数需要不同的执行计划。

Answer 14

我遇到了类似的问题：一个返回4,000行且在1秒内运行的查询在SSRS中花了这么长时间才超时。

事实证明，问题是由SSRS处理多值参数的方式引起的。有趣的是，如果用户选择了多个值，则报告会快速呈现（约1秒），但如果只选择了一个值，则报告需要几分钟才能呈现。

这是原始查询，渲染时间超过了它应该超过100倍：

SELECT ...
FROM   ...
WHERE  filename IN (@file);
-- @file is an SSRS multi-value parameter passed directly to the query

我怀疑问题是SSRS引入了整个源表（超过100万行），然后执行客户端过滤器。

为了解决这个问题，我最终通过表达式将参数传递给查询，以便我可以自己控制过滤器。也就是说，在＆＃34; DataSet Properties＆＃34;窗口，在＆＃34;参数＆＃34;屏幕，我用这个表达式替换了参数值：

=JOIN(Parameters!file.Value,",")

...（我还给结果一个新名称：filelist），然后我将查询更新为：

SELECT ...
FROM   ...
WHERE  ',' + @filelist + ',' LIKE '%,' + FILENAME + ',%';
-- @filelist is passed to the query as the following expression:
-- =JOIN(Parameters!file.Value,",")

我猜想将查询移动到存储过程也是缓解问题的有效方法（因为SSRS在将多值参数传递给存储过程之前基本上执行相同的JOIN）。但就我而言，在报告中处理这一切并不简单。

最后，我应该注意LIKE运算符可能不是过滤项目列表的最有效方法，但它的编码肯定比分裂字符串方法简单得多，现在报告运行在大约一秒钟之内，所以拆分字符串似乎不值得付出额外的努力。

SSRS表现

14 个答案: