0

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

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

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

4

3 回答 3

2

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

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

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

于 2014-05-08T04:13:02.403 回答
0

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

 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.
于 2015-04-27T17:42:35.467 回答
-1

为了防止死锁启用两者

ALLOW_SNAPSHOT_ISOLATION 和 READ_COMMITTED_SNAPSHOT

ALTER DATABASE [BD] SET READ_COMMITTED_SNAPSHOT ON；ALTER DATABASE [BD] 设置 ALLOW_SNAPSHOT_ISOLATION ON；

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

于 2013-10-25T15:39:51.210 回答