Reporting services Reporting Services 2014-导航栏显示0个，共0个

背景：

我们最近迁移到SSRS 2014；我们的源数据库是SQL Server 2008 R2。我们在一个报告中遇到了一些性能问题，在该报告中，它将停止响应，并最终在呈现报告时在30分钟后超时。查看报表服务器上的执行日志表明数据检索时间较短，而报表呈现时间较长。DBA在这个问题出现一个月后发现的解决方案是将READ_COMMITTED_SNAPSHOT设置为ON

这似乎用一个报告解决了非常奇怪的性能问题。当用户试图生成此报告时，它似乎会陷入僵局。死锁似乎出现在临时报表服务器数据库上，仅在将报表返回浏览器IE或Chrome时发生，并非每次生成报表时都会发生，但在多个用户试图在同一时间段内生成报表时可能会发生死锁。报告有3个级别的分组，并为输入的参数返回可变的行数

此设置READ_COMMITTED_SNAPSHOT现在似乎导致了第二个问题：在报告的导航栏中，用户可以在报告上的页面中导航，当激活的“下一页”按钮时，最初显示0中的0。当用户单击“下一页”按钮时，浏览器会像导航到下一页一样执行回发，并用第一页刷新屏幕。现在，导航栏显示X的1

我们所有的SSRS服务器都收到了READ_COMMITTED_SNAPSHOT ON，所以我要求DBA将我的DEV服务器更新为OFF。当这项工作完成后，我重新生成了大约12个报告，每个报告最初都显示了X个页面中的1个，正如我预期的那样。现在，我怀疑将此属性设置为ON是否是修复报告的正确方法

我考虑过创建报表快照是否是一个好的解决方案，不幸的是，我不认为这是因为我们有不同参数选择的用户

问题:

是否有更好的方法解决上述报告性能问题，而不是将READ_COMMITTED_SNAPSHOT设置为on？ 如果一个为true/on，则READ\u COMMITTED\u SNAPSHOT和ALLOW\u SNAPSHOT\u隔离是否都需要设置为true/on？ 是否有人遇到过与SSRS中的导航栏相关的问题，以及他们是如何解决该问题的？ 更新：

---

我们最终不得不回滚READ_COMMITTED_快照设置，因为它导致了一个完全不同的错误。上述问题似乎也得到了解决，连续两个月没有报告任何问题。不幸的是，没有人知道首先是什么导致了这个问题，或者是什么修复了它——可能是硬件的改变

我假设您在报告的源数据库上更改了这些设置，而不是SSRS服务器本身，除非它们是相同的服务器。更改READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION的设置会对您的系统产生广泛的影响，因此应谨慎操作。有关更改这些设置的潜在问题以及第二个问题的答案，请参阅

在我看来，问题似乎出在一个或多个报表查询中，因此更改这些数据库级别设置以解决一个报表中的性能问题可能有些过分。在更改行版本控制设置之前，我将首先分析报表查询并对其进行调优，可能还会向源数据库添加缺少的统计信息或索引

---

至于导航栏问题，可能行版本控制的更改意味着SSRS无法计算初始加载页面时可用的页面数。但是我不知道为什么会发生这种情况

我们在SSRS临时数据库中添加了READ_COMMITTED_快照；不是报告的源数据库；因为执行日志表明数据检索时间较短，而ReportRendering时间较长。当我们在Dev服务器上设置READ_COMMITTED_SNAPSHOT进行测试时，导航栏问题似乎得到了解决。但是，我们无法在pre-prod环境中测试报表的性能，因为pre-prod中没有并发用户。Reporting Services文档明确指出，对于报表服务器和报表服务器临时数据库，READ_COMMITTED_SNAPSHOT和ALLOW_SNAPSHOT_ISOLATION应设置为OFF。将此更改为ON将使您处于Reporting Services配置不受支持的状态：Nathan，谢谢您的参考。我将审查它们并将它们转发到数据库中。报告呈现看起来像执行日志中的瓶颈的可能原因是什么？当运行查询或在ssms中执行存储过程时，查询将在可接受的时间内返回~