Read Committed Snapshot Isolation：更新冲突回滚是否显示为死锁？答案

【问题标题】：Read Committed Snapshot Isolation: Does Update Conflict Rollback appear as Deadlock?Read Committed Snapshot Isolation：更新冲突回滚是否显示为死锁？
【发布时间】：2015-04-28 01:42:35
【问题描述】：

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

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

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

【问题讨论】：

如果您得到的错误是死锁错误，那么是的，死锁图将是可追踪的。 RE：您对表结构和查询的描述会很有用，因为描述有点模棱两可，但无论如何听起来您可以通过BEGIN TRAN 在两个单独的 SSMS 窗口中轻松测试自己，然后按照您的理论顺序运行各个语句。
@MartinSmith 我可以证明发生了死锁；那是绝对已知的。问题是我对正在发生的事情的理解是否正确，或者是否是不同的逻辑导致了僵局。该查询不相关，因为当存储过程的多个实例并行运行时，它发生在存储过程中多个位置的多个不同查询中。我只是想知道更新冲突是否会显示为死锁，或者是否会显示为不同的东西。如果它确实显示为死锁，那么我有我的解释；如果没有，那就回到绘图板。

标签： sql-server deadlock trace read-committed-snapshot snapshot-isolation

【解决方案1】：

在附加到原始问题的评论中，您说：“我只是想知道更新冲突是否会显示为死锁，或者是否会显示为不同的东西。”当我开始研究使用快照隔离时，我实际上有这些类型的担忧。最终我意识到 READ_COMMITTED_SNAPSHOT 和隔离级别 SNAPSHOT 之间存在显着差异。

前者使用行版本控制进行读取，但继续使用排他锁定进行写入。因此，READ_COMMITTED_SNAPHOT 实际上介于纯悲观和纯乐观并发控制之间。因为它使用锁进行写入，所以不可能发生更新冲突，但会出现死锁。至少在 SQL Server 中，这些死锁将被报告为死锁，就像使用“正常”悲观锁定一样。

后者（隔离级别SNAPSHOT）是纯粹的乐观并发控制。行版本控制用于读取和写入。死锁是不可能的，但更新冲突是可能的。后者被报告为更新冲突而不是死锁。

【讨论】：

【解决方案2】：

快照事务被回滚，并收到以下错误消息：

 Msg 3960, Level 16, State 4, Line 1
 Snapshot isolation transaction aborted due to update conflict. You cannot use snapshot
 isolation to access table 'Test.TestTran' directly or indirectly in database 'TestDatabase' to
 update, delete, or insert the row that has been modified or deleted by another transaction.
 Retry the transaction or change the isolation level for the update/delete statement.

【讨论】：

【解决方案3】：

为了防止死锁启用两个

ALLOW_SNAPSHOT_ISOLATION 和 READ_COMMITTED_SNAPSHOT

ALTER DATABASE [BD] SET READ_COMMITTED_SNAPSHOT ON; ALTER DATABASE [BD] SET ALLOW_SNAPSHOT_ISOLATION ON;

在这里解释差异 http://technet.microsoft.com/en-us/sqlserver/gg545007.aspx

【讨论】：