快速查询在SSRS中运行缓慢


78

我有一个SSRS报告,可以调出存储过程。如果直接从查询窗口运行存储过程,它将在2秒内返回。但是,从2005 SSRS报表运行的同一查询最多需要5分钟才能完成。这不仅发生在第一次运行中,而且每次都发生。此外,在其他环境中我看不到相同的问题。

关于SSRS报告为何在这种特定环境中运行如此缓慢的任何想法?


1
您的sp有参数吗?
Irwin M. Fletcher

1
是的,它有大约9个参数。报表参数类型与存储过程参数类型匹配。
user275554'2

随时接受您自己的答案,以便该问题可以用作重复问题。
Dale K

Answers:


110

感谢您在此处提供的建议。我们找到了一个解决方案,它确实与参数有关。由于“参数嗅探”,从SSRS报告执行时,SQL Server正在生成复杂的执行计划。解决方法是在存储过程中声明变量,并将传入参数分配给变量。然后查询使用变量而不是参数。这导致查询无论从SQL Server Manager还是通过SSRS报表调用都可以一致地执行。


这是SQL Server的已知问题……实际上与SSRS本身无关。
AlexCode 2013年

rr!感谢您发布解决方案和问题。它正确地优化了Fri,进入DOA,将参数重新分配给新的变量,并恢复正常。
Volvox

3
除了重新分配所有变量外,您还可以将查询标记为OPTIMIZE FOR UNKNOWN。参见stackoverflow.com/questions/12979493/…–
麦克(Mike)

1
这也为我工作。我只有重新分配一个四个变量,使其工作。
达伦·格里菲斯

16

将此添加到您的过程的末尾: option(recompile)

这将使报表的运行几乎与存储过程一样快


实际上,每次您运行存储过程时,它都会重新编译存储过程。我不确定这是否是一个好的解决方案,因为它违反了存储过程的目的。
Yodacheese 2013年

6
如果有单个查询运行缓慢,则在查询级别添加一个选项(重新编译)会产生很大的不同。只需记住:重新编译=优化。如果您需要查询在非常短的时间内(例如100毫秒或以下)运行,则重新编译时间可能不可接受,并且绕过参数嗅探可能对您更好。但是,对于耗时数分钟才能完成的大型报告,与具有不良查询计划的代价相比,重新编译的成本可以忽略不计。
Paul Williams

14

我将补充说,对于非存储过程查询,我也有同样的问题-只是一个普通的select语句。为了解决这个问题,我在数据集SQL语句中声明了一个变量,并将其设置为等于SSRS参数。

多么烦人的解决方法!不过,感谢大家使我接近答案!


3
感谢您分享这个。我也在做非存储过程方法,这节省了我很多时间。
鲍勃·霍恩

1
参数嗅探;尤其是如果前端具有一堆参数。将它们重新设置为内部参数对我来说是成功的诀窍,因此我投票赞成该答案。在我有8个报告参数的情况下,重新编译的选项不起作用;3,具有多参数值。
junketsu

11

我遇到了同样的问题,这是我对问题的描述

“我创建了一个存储过程,该过程将生成2200行,并在将近2秒钟内执行,但是在从SSRS 2008调用存储过程并运行报告后,该过程实际上从未运行过,最终我不得不杀死BIDS(商业智能开发工作室)来自任务管理器”。

我尝试过的事情:我尝试从reportuser登录运行SP,但是该用户的SP也正常运行,我检查了Profiler,但没有解决。

解:

实际上,问题在于,即使SP正在生成结果,但SSRS引擎仍需要花费时间来读取这些多行并将其呈现回去。所以我在SP中添加了WITH RECOMPILE选项并运行了报告..这是奇迹发生的时间,我的问题得到解决。


5

我发生了相同的情况。.非常基本的报告,SP(仅包含1个参数)花了5秒钟才能带回10K记录,但是该报告需要6分钟才能运行。根据事件探查器和RS ExecutionLogStorage表,该报告将所有时间都花在查询上。Brian S.的评论使我找到了解决方案。.我只是在SP中的AS语句之前添加了WITH RECOMPILE,现在报告时间几乎与SP执行时间匹配。


5

我只是在Tablix属性中取消选择了“在每个页面上重复标题列”。


是的,现在取消选择大约10秒后呈现的报告之前,它会在2秒内呈现。
2012年

5

如果您的存储过程使用链接服务器openquery,它们可能会自行快速运行,但要花很长时间才能在SSRS中呈现。一些一般性建议:

  • 通过使用其他数据源而不是使用链接的服务器来检索数据,直接从存储数据的服务器中检索数据。
  • 在执行报告之前,将数据从远程服务器加载到本地表,以使报告查询保持简单。
  • 使用表变量首先从远程服务器检索数据,然后与本地表联接,而不是直接返回与链接服务器的联接。

我看到问题已经得到回答,我只是在添加这个,以防有人遇到同样的问题。


5

我在检索32000行的报告中遇到了报告html输出问题。查询运行速度很快,但进入Web浏览器的输出非常慢。就我而言,我必须激活“交互式分页”以允许用户查看首页并能够生成Excel文件。该解决方案的优点是首页显示速度快,用户可以生成导出到Excel或PDF,缺点是用户只能滚动当前页面。如果用户想查看更多内容,则必须使用网格上方的导航按钮。在我的情况下,用户接受此行为是因为导出到Excel更重要。

要激活“交互式分页”,必须在报告窗格中单击可用区域,然后在“属性”窗格中的报告级别上更改属性“ InteractiveSize” \“高度”。将此属性设置为不同于0的值。在我的情况下,我设置为8.5英寸。还要确保您在Tablix级别上未选中“如果可能,请保留在一页上”属性(右键单击Tablix,然后单击“ Tablix属性”,然后单击“常规” \“分页选项”)。

在此处输入图片说明


这为我解决了!
根据

4

我遇到了类似的问题,即存储过程从Management Studio快速执行,但从SSRS执行非常慢。经过长时间的努力,我通过物理删除存储过程并重新创建它来解决了此问题。我不确定其背后的逻辑,但我认为这是由于存储过程中使用的表结构发生了变化。


3

我面临着同样的问题。对我来说,这只是解开选项:

Tablix属性=>分页选项=>如果可能,请放在一页上

SSRS报告。它试图将所有记录放在同一页上,而不是创建许多页。


3

除了参数嗅探问题之外,我发现SSRS在客户端处理上通常比(在我的情况下)Crystal报表要慢。当SSRS引擎有很多要本地过滤或聚合的行时,SSRS引擎似乎没有能力。诚然,这些都是结果集设计问题,可以经常解决(尽管在钻取时需要详细信息,但并非总是可以解决),但越成熟的报告引擎就越容易理解。


3

就我而言,我只需要断开并连接SSMS。我对查询进行了概要分析,即使查询本身运行时间不到2秒,执行时间也显示为1分钟。重新启动连接并再次运行,这次持续时间显示正确的执行时间。


1

您可以在不执行实际报告的情况下做几件事,只需在Reporting Services的“数据”标签中运行sproc。还需要时间吗?另一个选择是使用SQL事件探查器,确定要进出数据库系统的内容。

您可以做另一件事来测试它,以便重新创建一个没有任何参数的简单报表。运行报告,看看它是否有所作为。RS报告可能已损坏或格式不正确,可能会导致渲染速度变慢。


1

遇到相同的问题,并通过为共享数据集提供默认参数并在报表服务器中更新该数据集来解决此问题。


1

您在SSRS表中使用“分组依据”吗?

我有一个按字段分组的3个报告,我注意到尽管查询很简单,但是报告运行非常缓慢,以至于我什至无法在搜索字段中拨打值。

比起我,我删除了分组,现在报告在几秒钟内上升,所有内容立即生效。


1

我可以通过从底部删除[&TotalPages]内置字段来解决此问题。从几分钟降至不到一秒的时间。

我无法确定的奇怪之处在于影响了总页数的计算。

我正在使用SSRS 2012。


-1

在我们的情况下,不需要代码。

我们的服务台提供的注释:“清除Internet设置将解决此问题。”

也许这意味着“清除缓存”。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.