打开ALLOW_SNAPSHOT_ISOLATION是否有任何缺点

Question

我们的数据库目前正在遇到阻塞，死锁和超时问题，我们正在慢慢开始解决这些问题。我遇到了快照隔离级别的概念。我不认为我们的应用程序已准备好启用Read Comitted Snapshot，但我确实认为cut(i$rminute, c(0, 16, 31, 46, Inf), 1:4) 正在被打开，而某些有ALLOW_SNAPSHOT_ISOLATION标志的有问题的查询可能会有很大的帮助。关于使用读取提交的快照启用时需要进行测试的各种警告，我理解为什么，但我只是想查看是否有关于打开set transaction isolation level snapshot的问题。从我的角度来看，没有任何东西，因为没有任何东西可以神奇地交换使用快照隔离级别，就像读取提交的快照启用一样。它只会影响我们将隔离级别设置为快照的查询/ sprocs / etc。任何人都可以确认或否认吗？

Answer 1

启用ALLOW_SNAPSHOT_ISOLATION（或READ_COMMITTED_SNAPSHOT）数据库选项的缺点是为所有数据库事务维护行版本的额外开销。开销包括在tempdb中维护行版本存储以及每行额外存储14个字节的存储空间。 {（3}}详细介绍了此开销。

即使您实际上没有使用SNAPSHOT隔离，如果ALLOW_SNAPSHOT_ISOLATION启动，SQL Server仍将在启用SNAPSHOT的数据库中维护行版本。行版本控制开销的整体性能和存储影响在很大程度上取决于您的工作负载和环境。它可能不会阻止您使用SNAPSHOT隔离，但您需要进行测试以确定您的情况会产生什么影响。肯定有并发优势可以抵消成本。

Answer 2

它将消除读写之间的所有阻塞。但是，如果在同一页面上同时发生两次写入，则仍可能发生阻塞。没有办法解决这个问题。

根据我的经验，由于快照隔离（行版本控制）导致的额外负载可以忽略不计，行版本控制在减少被阻止的读取器方面的好处是巨大的。

Answer 3

启用快照隔离后，旧行版本将保留在 tempdb 中，直到可以使用它们的事务完成。因此，如果您有一个事务意外打开，tempdb 可能会填满，直到灾难发生。