我们的生产环境中存在一个非常令人沮丧的问题。
我们的报告有时会很快返回，有时则根本不会返回。当问题发生时，报告将处理15分钟左右，然后浏览器将显示“无法显示网页”错误。这个问题是零星的，通常会持续几天，然后我们会得到几天非常快的处理，然后又回到慢速。当报告运行正常时，我们可以在大约10秒内返回超过14k的记录。
我们的数据团队告诉我，当我们看到从慢速切换到快速切换时，SQL Server上没有发生任何事情。没有索引重建，统计重新计算等。
底层报表查询（存储过程）总是快速运行。即使我们遇到问题，我也可以使用与报表使用的用户相同的用户连接到生产数据库，并使用相同的参数运行存储过程，并且它总是快速返回。我们检查了阻塞，但没有发生任何事情。
该报告确实有很多参数。我看过关于“参数嗅探”的帖子，所以我创建了一个参数免费版本的报告，我仍然得到相同的结果。
这份报告没有什么复杂的。这是一张桌子。在报告级别没有进行分组或过滤。没有子报告。该报告确实使用了交互式排序。
该报告可以返回超过14k的记录。这方面的数据总量约为2MB。但就像我之前所说的那样，有些日子报告运行良好，并且会在几秒钟内返回最大量的记录。
该报告使用的共享数据源也会被许多其他未遇到此问题的报告使用。
在报告数据库中，我们看到记录被添加到RunningJobs表中以获取这些报告请求，但之后我们看不到任何处理。这就像报表服务器忘记了它们。
我们当前的路线或想法是报表服务器运行不正常，因为RunningJobs中的这些条目只是坐在那里而且没有处理。
有谁知道为什么一份工作可能会在RunningJobs表中？如果正在运行这些作业，我们应该在Report Server日志文件中看到一些内容，对吗？还有什么我们应该测试的吗？
我们的报告服务器版本为9.00.3050.00。我们正在通过Report Viewer网络控件进行访问。
答案 0 :(得分：1)
也许尝试一个较小的数据集，看看是否会改变它。
任一服务器上的任何CPU spikage？
报告的运行时间是否与您遇到的情况相符？ ReportServer中的ExecutionLog表应显示此内容。
听起来很烦人 - 我同情，希望我有更好的想法。
答案 1 :(得分：1)
您是否尝试使用SQL Server Profiler配置请求？使用它可以确定请求是否已在SQL Server中完成，问题在于生成报告，或者查询实际上是否未完成。
如果查询在缓慢时没有完成，您可以捕获查询计划并将其与您遇到问题时生成的计划进行比较。
答案 2 :(得分：0)
我还没有使用过ReportServer（到目前为止），但我看到了SQL服务器的类似问题，这只是由故障的网络交换机（或其他网络硬件）引起的。一些数据包丢失，应用程序无限期地等待服务器 - 并且服务器上绝对没有任何活动。
答案 3 :(得分：0)
我能够解决在切换数据库服务器并在web.config中更新了连接字符串后发生的类似问题。我的查询运行时间大约为5-6秒，但报告花了很长时间才超出我的网页（我使用的是本地报告;我没有报告服务器。）
我怀疑我的DAL中的DataTables在继续使用新服务器之前仍然在寻找旧服务器。我可能对这个想法不以为然，但它的解决方案仍然有效！
我通过在右键单击菜单中选择“配置”来刷新我的.xsd文件中的所有DataTable，并保留所有默认值，单击Next直到我必须单击Finish。在浏览了每个DataTable后，我重新构建了网站，现在它的运行速度与查询速度一样快。
我希望这有帮助！
答案 4 :(得分：0)
确认您的报告中没有包含外部链接的图像。如果这样做，图像主机可能需要很长时间才能成为服务器。我有一个非常类似的情况，报告服务器丢失了出站互联网访问，因此报表服务器无法在处理过程中检索外部图像。不幸的是，SRRS不只是检查，得到一个http错误，然后返回，等待，等待。我supsect（但尚未验证）它试图检索报告的每个页面的图像。我这样说是因为报告长度和旧执行时间之间的差异与问题存在时的执行时间之间存在差异。报告的每一页似乎都有5到12秒的延迟。
如果您想了解我如何修复问题的详细信息，请参阅我的帖子：
SQL Server Reporting Services - Fast TimeDataRetrieval - Long TimeProcessing
亲切的问候，
伯尼