5

I've spent hours troubleshooting this and I need some fresh perspective . . .

We have a relatively simple report setup in SSRS, simple matrix with columns across the top and data points going down. The SQL query behind the report is "medium" complexity -- has some subqueries and several joins, but nothing real crazy.

Report has worked fine for months and recently has become REALLY slow. Like, 15-20 minutes to generate the report. I can clip-and-paste the SQL query from the Report Designer into SQL Mgmt Studio, replace the necessary variables, and it ruturns results in less than 2 seconds. I even went so far as to use SQL profiler to get the exact query that SSRS is executing, and clipped-and-pasted this into Mgmt Studio, still the same thing, sub-second results. The parameters and date ranges specified don't make any difference, I can set parameters to return a small dataset (< 100 rows) or a humongous one (> 10,000 rows) and still the same results; super-fast in Mgmt Studio but 20 minutes to generate the SSRS report.

Troubleshooting I've attempted so far: Deleted and re-deployed the report in SSRS. Tested in Visual Studio IDE on multiple machines and on the SSRS server, same speed (~20 minutes) both places Used SQL Profiler to monitor the SPID executing the report, captured all SQL statements being executed, and tried them individualy (and together) in Mgmt Studio -- runs fast in Mgmt Studio (< 2 seconds) Monitored server performance during report execution. Processor is pretty darn hammered during the 20 minute report generation, disk I/O is slightly above baseline

4

2 回答 2

6

检查两者的执行计划，以确保参数嗅探和/或 set_options 中的差异的组合没有生成两个单独的执行计划。

这是我在从 ADO.Net 和 SSMS 执行查询时遇到的情况。当使用不同的选项创建不同的执行计划时，就会出现问题。SQL Server 利用传入的参数值来尝试进一步优化生成的执行计划。我发现每个生成的执行计划都使用了不同的参数值，从而产生了最优和次优计划。目前我找不到用于检查此问题的原始查询，但快速搜索会发现与同一问题相关的这篇文章。

http://www.sqlservercentral.com/blogs/sqlservernotesfromthefield/2011/10/25/multiple-query-plans-for-the-same-query_3F00_/

如果您使用的是 SQL Server 2008，还可以通过名为“OPTIMIZE FOR UNKNOWN”的查询提示提供替代方法，该方法实质上禁用了参数嗅探。下面是一篇文章的链接，该文章帮助我对该功能进行了原始研究。

http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature.aspx

对于早于 2008 的版本，上述方法的替代方法是将参数值存储在过程中的局部变量中。这与上面的查询提示的行为方式相同。这个提示来自下面的文章（在编辑中）。

编辑

多一点搜索发现了一篇文章，对这个主题进行了非常深入的分析，以防万一它有任何用处，链接如下。

http://www.sommarskog.se/query-plan-mysteries.html

于 2012-11-02T19:37:53.717 回答
5

这个问题对我们来说也是一个问题。我们正在运行来自 CRM 2011 的 SSRS 报告。我尝试了一些建议的解决方案（将输入参数映射到局部变量，将 WITH RECOMPILE 添加到存储过程），但没有任何运气。

这篇关于报表服务器应用程序内存配置的文章 ( http://technet.microsoft.com/en-us/library/ms159206.aspx )，更具体地说，将 4000000 值添加到我们的 RSReportServer.config 文件中解决了这个问题。

需要 30-60 秒才能呈现的报告现在在不到 5 秒的时间内完成，这与在 SSMS 中执行底层存储过程所需的时间大致相同。

于 2013-09-11T18:09:22.610 回答