在sql-server中开启读提交快照有什么风险？

Question

我在这里读到每行将存储一些额外的数据，因此我们可能会看到性能下降，但还有哪些其他风险？

例如。这会影响数据库的恢复吗？我们还需要做些什么来利用这一点吗？

我计划执行这些命令：

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

我相信这会让我们更接近 oracle，如果一个事务正在更新其他事务仍然可以读取旧数据。这样对吗？

我正在研究这个，因为我厌倦了 SQL Server 2005 中的锁定问题。我希望这可以减少我们的用户看到的偶尔的死锁，帮助我们的应用程序的整体性能并鼓励我们的开发人员在没有害怕。

Answer 1

概括

1. 如果您有锁定问题，那么您的代码就有问题：它不是数据库引擎
2. 这不是灵丹妙药
3. 您可能会添加更多问题

加载

它还会增加 tempdb 和CPU 的负载。另见：

• “性能影响：Read_Committed_Snapshot 的潜在成本”（Linchi Shea）

安全

最重要的是，默认情况下，快照隔离在许多情况下并不安全。阅读“快照隔离”（维基百科）了解更多关于写偏斜异常的信息。下一节是“使快照隔离可序列化”来解决这个问题。

因此，总的来说，快照隔离将一些维护非平凡约束的问题放在用户身上，他们可能不了解潜在的陷阱或可能的解决方案。这种转移的好处是性能更好。

另见：

• “读提交快照隔离级别的潜在危险”（JimMcLeod，在 Alex Kuznetsov 的评论中提出异议）
• 死锁！：“读取提交的快照”解释（尼克贝拉迪）
• Serializable vs. Snapshot Isolation Level，Marble 问题(Craig Freedman)
• READ_COMMITTED_SNAPSHOT 下涉及 UDF 的读取可能看起来不一致(Alex Kuznetsov)

Answer 2

我知道这是一个旧线程，但我会说在很大程度上快照隔离是一个神奇的子弹。它将消除读者和作者之间的所有障碍。然而，它不会阻止作者阻止其他作者。没有办法解决这个问题。

根据我的经验，TEMPDB 上的额外负载可以忽略不计，行版本控制在减少阻塞读取器方面的好处是巨大的。

作为参考，行版本控制（快照隔离）是 Oracle 几十年来用来在不阻塞读取器的情况下实现隔离的方法，而且我使用了近 20 年的 Oracle DB 遇到的阻塞问题远少于 SQL Server。大多数 SQL 开发人员对使用快照隔离犹豫不决，因为他们只针对使用默认设置的数据库测试了他们的代码。

Answer 3

要添加到其他答案中的几点：

SET ALLOW_SNAPSHOT_ISOLATION ON仅在数据库中启用快照隔离。要利用它，您必须重新编码并SET TRANSACTION ISOLATION LEVEL SNAPSHOT为您希望它应用到的交易。需要更改调用代码以处理更新冲突错误。

之后SET READ_COMMITTED_SNAPSHOT ON，读取提交的语句使用行版本控制。请注意，这是只读的语句级行版本控制。对于更新，检索“真实”行并应用更新锁。请参阅了解基于行版本控制的隔离级别中的行为摘要部分

无论哪种方式，如果没有进行详尽的测试，您都可能会给系统带来一系列全新的问题。

Answer 4

我相信这会让我们更接近 oracle，如果一个事务正在更新其他事务仍然可以读取旧数据。这样对吗？

是的，这是正确的。

非常值得阅读 gbn 答案中的链接，我相信这同样适用于 Oracle 的默认 MVCC 以及快照隔离模式下的 SQL Server。我想补充一点，如果你了解潜在的陷阱，IMO 的好处远远超过增加的困难（从 Oracle 的角度来看）——当然，一些锁定问题合法地消失了，这就是 MVCC（还有一类由于代码问题而不会消失的锁定问题，但我假设您理解这一点）。

Answer 5

我们在所有使用 SQL Server DB 的项目中都使用 SNAPSHOT ISOLATION。不再有 1205 SQL 错误，这些错误不是由错误的应用程序代码引起的，而是由默认的页锁定和行锁定行为引起的。

性能影响很小，到目前为止 7 年过去了，在不同的系统中处理了数亿次操作，没有关于快照隔离的问题。

多个不同线程并行更新单行业务关键信息的情况非常特殊，快照隔离导致任何不一致问题的可能性几乎为零。

如果您有一个 OLTP 系统，根据设计在许多线程中根据当前行数据更新单行，当然在这种情况下 SNAPSHOTS 是不可接受的。