0

背景：

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

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

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

我们所有的 SSRS 服务器都收到了 READ_COMMITTED_SNAPSHOT ON，所以我要求 DBA 将我的 DEV 服务器更新为 OFF。完成后，我重新生成了所有报告（大约一打），并且每个报告最初都显示了 X 页中的 1 个，正如我所预料的那样。现在，我质疑将此属性设置为 ON 是否是修复报告的正确方法。

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

问题：

  1. 有没有更好的方法来解决上面的报告性能问题，而不是将 READ_COMMITTED_SNAPSHOT 设置为 on？
  2. READ_COMMITTED_SNAPSHOT 和 ALLOW_SNAPSHOT_ISOLATION 是否都需要设置为 true/on（如果有的话）？
  3. 有没有人遇到过与 SSRS 中的导航栏相关的问题，他们是如何解决这个问题的？

更新：

我们最终不得不回滚 READ_COMMITTED_SNAPSHOT 设置，因为它导致发生完全不同的错误。上面概述的问题似乎也得到了解决，连续两个月没有报告任何问题。不幸的是，没有人一开始就知道是什么导致了这个问题，或者是什么解决了这个问题（可能是硬件更改）。

4

1 回答 1

0

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

对我来说，听起来问题出在您的一个或多个报表查询中，因此更改这些数据库级别设置以解决一个报表中的性能问题可能是矫枉过正。在更改行版本控制设置之前，我将首先分析您的报告查询并对其进行调整（并可能将缺少的统计信息或索引添加到源数据库）。

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

于 2015-09-02T02:30:03.727 回答