我收到了一份每月运行12,000次的SQL 2008R2报告。每次执行平均为60-90秒。
我已经使用SQL 12年了,但我刚刚在2-3周前开始这项工作,我仍然试图解决一些这些SSRS性能问题。不言而喻,为了帮助报告,我已经重新编制了所有内容的索引。
这是我执行日志的图片/转储:
SELECT ReportPath, TimeDataRetrieval, TimeProcessing, TimeRendering, Source, [RowCount]
FROM ReportServer.dbo.ExecutionLog2
WHERE UserName = '_________' AND ReportAction = 'Render'
ORDER BY timeStart desc
http://accessadp.com/?attachment_id=562
ReportPath TimeDataRetrieval TimeProcessing TimeRendering Source RowCount
/CubeReports/Freight Allocation 2954 4402 2039 Live 2348
/RS Reports/Freight Allocation 39954 4087 2380 Live 2348
/RS Reports/Freight Allocation 37718 3948 1888 Live 2348
/RS Reports/Freight Allocation 39534 4317 1937 Live 2348
/CubeReports/Freight Allocation 3257 4206 2422 Live 2348
/RS Reports/Freight Allocation 37517 4164 2402 Live 2348
/RS Reports/Freight Allocation 36127 4151 1986 Live 2348
/RS Reports/Freight Allocation 36415 39888 2569 Live 19048
/RS Reports/Freight Allocation 37544 41644 2071 Live 19048
/RS Reports/Freight Allocation 37970 41003 2187 Live 19048
/RS Reports/Freight Allocation 38057 48085 1885 Live 19048
/CubeReports/Freight Allocation 3030 4558 2056 Live 2348
/CubeReports/Freight Allocation 3534 5232 2422 Live 2348
请注意,我相信我知道' RowCount'是。我有一个运行数据集的子报表(这并不重要),我删除了它。
我认为这是性能提升的原因..但我已经仔细检查并三次检查了subReports不再拥有其他数据集(这是在rowcount的减少中引用的) 。不幸的是,这并没有转化为处理时间的减少。
我从“RS报告”中下载了该报告,并将其部署到了“CubeReports”,并且我没有对此版本的报告进行任何其他更改。< / p>
我使用相同的参数运行它..现在报告的副本&#39; CubeReports&#39;字面上快了10倍。
我无法弄清楚为什么会发生这种情况? 我真的需要找到解决方案并将其投入生产。
我已经检查了快照,历史记录,执行缓存..没有打开,这看起来都是两个报告的默认设置..我已经检查了所有其他选项,我只是无法找到任何可以解释这一点的东西。
我看到的唯一三个选项:
不幸的是,我已经能够始终如一地复制10倍的速度提升,我使用相同的参数运行了大约10次,结果相同。请记住,只有1个SSRS服务器,与1个数据库服务器相对。相同的sprocs,相同的参数。
本报告的生产副本中性能下降了10倍。 将其复制到新文件夹时性能提高10倍。
主ERP数据库大约100GB,只有4个核心,只有16GB RAM。 SSRS Server位于VM上,它只有2个内核,只有8GB内存。
SSRS服务器上还有一个额外的数据库;它实际上是一个相当大的数据库 - 但不是TON的活动。另一个数据库(Bartender)只有9gb数据/ 3gb日志。
答案 0 :(得分:0)
您可能会遇到两个单词文件夹名称的问题。尝试使用其名称中的空格的另一个文件夹并检查那里。
只是我的2美分...但我活着看到神圣的“我”宣布全球化。
答案 1 :(得分:0)
我最近遇到了类似的性能问题。使用SQL Server Profiler,我将其跟踪到完全相同的查询执行。它有时会导致读取的次数大约是其他查询的1000倍。差异似乎是查询是作为SQL还是通过RPC调用。
进一步深入研究,通过一些反复试验,我发现我的情况的主要区别在于ARITHABORT
的选项对于不同的连接或用户设置的方式不同。
不幸的是,我不记得在我的情况下哪个设置是快速的。我没有收到失败的查询,但此选项的状态导致使用不同的执行计划。在我的查询开头放置语句SET ARITHABORT ON
或SET ARITHABORT OFF
会使所有内容保持一致。 ARITHIGNORE和ANSI_WARNINGS是类似的设置,因此您也可以查看它们。