问题标签 [read-committed-snapshot]

有人可以帮助我了解何时在 SQL Server 中使用 SNAPSHOT 隔离级别而不是 READ COMMITTED SNAPSHOT 吗？

我知道在大多数情况下 READ COMMITTED SNAPSHOT 有效，但不确定何时进行 SNAPSHOT 隔离。

谢谢

如何查询 Sql Server 2005 中的读/写比率？有什么我应该注意的警告吗？

也许它可以在 DMV 查询、标准报告、自定义报告（即性能仪表板）或检查 Sql Profiler 跟踪中找到。我不确定。

我为什么在乎？

我正在花时间提高我的网络应用数据层的性能。它处理数百万条记录和数以千计的用户。

我正在研究的要点之一是数据库并发性。默认情况下，Sql Server 使用悲观并发——适合写入繁重的应用程序。如果我的应用程序读取量很大，我可能会将其切换为乐观并发（隔离级别：），read committed snapshot就像Jeff Atwood 对 StackOverflow 所做的那样。

我知道快照隔离可以解决这个问题，但我想知道 NOLOCK 在这种特定情况下是否安全，这样我就可以避免开销。

我有一个看起来像这样的表：

永远不会对表进行更新。可能会发生删除，但它们不应与 SELECT 竞争，因为它们会影响表的另一端、较旧的一端。插入是常规的，对 (Id, Date) 索引的页面拆分非常常见。

我在标准 INSERT 和 SELECT 之间出现了死锁情况，如下所示：

因为 INSERT 在 Cx (Date, Id; Value) 上获得锁，然后在 Ix (Id, Date) 上获得锁，但 SELECT 在 Ix (Id, Date) 上获得锁，然后在 Cx (Date, Id; Value) 上获得锁。这是因为 SELECT 首先在 Ix 上查找，然后加入到 Cx 上的查找。

交换聚集索引和非聚集索引会打破这个循环，但这不是一个可接受的解决方案，因为它会引入其他（更复杂的）SELECT 的循环。

如果我将 NOLOCK 添加到 SELECT，在这种情况下会出错吗？能否返回：

1. 不止一排，即使我要求 TOP 1？
2. 没有行，即使存在并已提交？
3. 最糟糕的是，一行不满足 WHERE 子句？

我已经在网上阅读了很多关于此的内容，但我所见过的计数过多或过少异常的唯一复制品（一、二）涉及扫描。这仅涉及搜索。Jeff Atwood有一篇关于使用 NOLOCK 的帖子引起了很好的讨论。我对 Rick Townsend 的评论特别感兴趣：

其次，如果您读取脏数据，您面临的风险是读取完全错误的行。例如，如果您的选择读取索引以查找您的行，那么当您的选择读取实际数据行时，更新会更改行的位置（例如：由于页面拆分或对聚集索引的更新） ，它要么不再存在，要么完全不同！

这是否可能仅使用插入而不进行更新？如果是这样，那么我想即使我在仅插入表上的搜索也可能很危险。

更新：

我试图弄清楚快照隔离是如何工作的。它似乎是基于行的，其中事务读取表（没有共享锁！），找到他们感兴趣的行，然后查看他们是否需要从 tempdb 中的版本存储中获取该行的旧版本。

但在我的情况下，没有一行会有多个版本，所以版本存储似乎毫无意义。如果发现该行没有共享锁，与只使用 NOLOCK 有何不同？

我有一个针对 SQL Server 2005 数据库使用 COM 数据访问层的大型 Web 应用程序。默认情况下，隔离级别为 READ_COMMITTED。现在我了解了 READ_COMMITTED_SNAPSHOT 隔离级别是如何工作的，并且阅读 MSDN 说你可以透明地打开它。但是，我仍然持怀疑态度。:) 如果我从 READ_COMMITTED 更改为 READ_COMMITTED_SNAPSHOT，是否以实施方式保证我的应用程序不会中断（不要假设应用程序按规定完成所有操作）？不会向 COM 层抛出额外的异常？事务语义是否相同？

PS。通过实现方式，我的意思是故意实现 READ_COMMITTED_SNAPSHOT 隔离级别以完全像 READ_COMMITTED 一样工作，只是使用行版本控制而不是锁？

感谢您对切换到这种隔离模式的任何见解或您自己的经验。

说，我有一个人表，它只有 1 行 -

在一个连接上

同时在另一个连接上：

Q1：我的选择是否有可能根据更新语句的时间返回这样的结果：

两个连接都不使用显式事务，并且都使用默认事务隔离级别 READ COMMITTED。

问题真的是为了帮助我理解，在 sql 语句开头获取的锁是否继续存在直到语句完成，或者语句是否有可能释放锁并重新获取相同的锁如果在同一语句中使用两次，则行？

Q2：如果在数据库上设置了，问题的答案会改变set read_committed_snapshot on吗？

我在微软的网站上读过 http://msdn.microsoft.com/en-us/library/ms173763.aspx

Sql Server 在读取数据时不请求锁，除非正在恢复数据库。

这是否意味着使用 READ_COMMITTED_SNAPSHOT/SNAPSHOT ISOLATION 的 Sql Server 根本不使用共享锁？这怎么可能？

例如，如果有 2 笔交易。第一个事务 T1 想要更新一些行。第二个事务 T2 开始读取同一行（此事务将他复制到某个输出缓冲区、响应缓冲区或在 Sql Server 中调用的任何内容）。同时事务 T1 开始更新该行（它首先创建了版本化行）。

事务T2是否有可能读取未提交的数据？请记住，事务 T2 在 T1 进行更新之前开始复制该行，因此该行上没有排他锁。

这种情况是否可能发生？如果在复制数据期间不对该行设置共享锁，如何避免这种情况？

我很好奇在数据库上使用 IsolationLevel.Snapshot 和 SET READ_COMMITTED_SNAPSHOT ON 的效果。IsolationLevel 枚举的文档记录了快照隔离的行为，这不是我们在我们的情况下要寻找的。

启用 READ_COMMITTED_SNAPSHOT 后，我们应该指定 IsolationLevel.Unspecified，还是根本不提供此值？或者，如果我们确实指定了 IsolationLevel.Snapshot，我们会实现启用 READ_COMMITTED_SNAPSHOT 的预期行为吗？

谢谢！

我已阅读提交的快照隔离并允许隔离ON我的数据库。我仍然收到死锁错误。我很确定我知道发生了什么...

1. 第一个事务在其事务开始时获得一个序列号。
2. 第二个在其事务开始时获得较晚的序列号，但在第一个事务已经获得它之后（第二个序列号比第一个更新）。
3. 第二个事务首先进入更新语句。当它检查行版本控制时，它会看到两个事务之前的记录，因为第一个事务尚未到达更新。它发现该行的序列号处于已提交状态并继续前进。
4. 第一个事务轮到它，就像第二个事务找到相同的提交序列号，因为它不会看到第二个事务，因为它比它自己更新。当它尝试提交时，它发现另一个事务已经更新了尝试提交的记录，并且必须回滚。

这是我的问题：此回滚是否会在跟踪中显示为死锁？

根据Entity Framework 网站中的这个链接READ_COMMITTED_SNAPSHOT，EF6 的默认事务隔离级别更改为.

对于使用 Code First 创建的数据库，默认事务隔离级别更改为 READ_COMMITTED_SNAPSHOT，这可能允许更高的可伸缩性和更少的死锁。

有没有办法将 EF(Code First) 早期版本的默认事务隔离级别设置为READ_COMMITTED_SNAPSHOT？

IBM DB2 9.7 是否有与 SQL Server 2008 相同的设置？该参数是 READ_COMMITTED_SNAPSHOT，可以设置为 ON，显然会影响锁定。