我花了几个小时解决这个问题,我需要一些新的视角。 。 。
我们在 SSRS 中有一个相对简单的报告设置,简单的矩阵,列位于顶部,数据点向下。报告背后的 SQL 查询是“中等”复杂性——有一些子查询和几个连接,但没有什么真正疯狂的。
报告几个月来一直运行良好,最近变得非常慢。比如,15-20 分钟即可生成报告。我可以将 SQL 查询从报表设计器剪切并粘贴到 SQL Mgmt Studio 中,替换必要的变量,并且它会在不到 2 秒的时间内返回结果。我什至使用 SQL Profiler 来获取exact查询 SSRS 正在执行的查询,并将其剪切并粘贴到 Mgmt Studio 中,仍然是同样的事情,亚秒结果。指定的参数和日期范围没有任何区别,我可以设置参数以返回小型数据集( 10,000 行),但结果仍然相同;在 Mgmt Studio 中速度超快,但只需 20 分钟即可生成 SSRS 报告。
到目前为止我已经尝试过的故障排除:
删除并在 SSRS 中重新部署该报告。
在多台计算机和 SSRS 服务器上的 Visual Studio IDE 中进行了测试,两个地方的速度相同(约 20 分钟)
使用 SQL Profiler 监视执行报告的 SPID,捕获正在执行的所有 SQL 语句,并在 Mgmt Studio 中单独(和一起)尝试它们 - 在 Mgmt Studio 中运行速度快(
检查两者的执行计划,以确保参数嗅探和/或 set_options 中的差异的组合不会生成两个单独的执行计划。
这是我在从 ADO.Net 和 SSMS 执行查询时遇到的场景。当使用不同的选项创建不同的执行计划时,就会出现问题。 SQL Server利用传入的参数值来尝试进一步优化生成的执行计划。我发现每个生成的执行计划使用了不同的参数值,从而产生了最优和次优计划。我目前找不到用于检查此问题的原始查询,但快速搜索显示了与同一问题相关的这篇文章。
http://www.sqlservercentral.com/blogs/sqlservernotesfromthefield/2011/10/25/multiple-query-plans-for-the-same-query_3F00_/ 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 http://blogs.msdn.com/b/sqlprogrammability/archive/2008/11/26/optimize-for-unknown-a-little-known-sql-server-2008-feature.aspx
对于 2008 年之前的版本,上述方法的替代方法是将参数值存储在过程内的局部变量中。这与上面的查询提示的行为方式相同。该技巧来自下面的文章(在编辑中)。
Edit
经过更多搜索,发现了一篇文章,其中对主题进行了非常深入的分析,以防有任何用处,链接如下。
http://www.sommarskog.se/query-plan-mysteries.html http://www.sommarskog.se/query-plan-mysteries.html
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)