快照隔离的读取和更新死锁

Question

在一个大量使用读和写的表上，许多死锁正在发生。因此，我正在尝试快照隔离。据我所知，读不应该阻止写，写不应该阻止读。不幸的是，这些操作仍然存在死锁，如下所示。

我是否错了我的期望，即那些死锁不应该发生在快照隔离？

unknown     
     
unknown     
    
    
(@__result_TransactionId_0 uniqueidentifier,@__destinationInstanceKey_1 nvarchar(50))SELECT [c].[Id], [c].[EntityId], [c].[EntityType], [c].[Error], [c].[FailureCount], [c].[InstanceKey], [c].[ReplicationScheduleOptions], [c].[ReplicationType], [c].[ScheduledAt], [c].[ScheduledById], [c].[Status], [c].[TransactionId], [c].[Metadata_ModifiedAt], [c].[Metadata_ModifiedById], [c].[Metadata_PublishedAt], [c].[Metadata_PublishedById], [c].[Metadata_PublishedStage]
FROM [ReplicationSchedule] AS [c]
WHERE ([c].[TransactionId] = @__result_TransactionId_0) AND ([c].[InstanceKey] = @__destinationInstanceKey_1)    
   
   
    
     
unknown     
     
unknown     
    
    
(@p3 uniqueidentifier,@p0 int,@p1 datetimeoffset(7),@p2 uniqueidentifier,@p7 uniqueidentifier,@p4 int,@p5 datetimeoffset(7),@p6 uniqueidentifier,@p11 uniqueidentifier,@p8 datetimeoffset(7),@p9 uniqueidentifier,@p10 nvarchar(4000),@p13 uniqueidentifier,@p12 datetimeoffset(7))SET NOCOUNT ON;
UPDATE [ReplicationSchedule] SET [Status] = @p0, [Metadata_ModifiedAt] = @p1, [Metadata_ModifiedById] = @p2
WHERE [Id] = @p3;
SELECT @@ROWCOUNT;

UPDATE [ReplicationSchedule] SET [Status] = @p4, [Metadata_ModifiedAt] = @p5, [Metadata_ModifiedById] = @p6
WHERE [Id] = @p7;
SELECT @@ROWCOUNT;

UPDATE [GummyBearPack] SET [Metadata_PublishedAt] = @p8, [Metadata_PublishedById] = @p9, [Metadata_PublishedStage] = @p10
WHERE [Id] = @p11;
SELECT @@ROWCOUNT;

UPDATE [GummyBearProductionCharge] SET [Metadata_PublishedAt] = @p12
WHERE [Id] = @p13;
SELECT @@ROWCOUNT;

Answer 1

快照数据库选项与问题中的死锁无关。

SELECT查询会话使用的是SERIALIZABLE事务隔离级别(如isolationlevel="serializable (4)在process xml元素中所示)，由于更严格的锁定，该级别特别容易出现死锁。SERIALIZABLE不使用行版本控制，并且不受READ_COMMITTED_SNAPSHOT或ALLOW_SNAPSHOT_ISOLATION数据库选项的影响。注意，正如@DavidBrowne在注释中提到的，使用TransactionScope的D7应用程序有时会不经意地使用SERIALIZABLE，因为这是默认的，除非指定了另一个隔离级别。

UPDATE查询会话使用的是READ COMMITTED，因此该会话上的只读查询将使用行版本控制，这是因为READ_COMMITTED_SNAPSHOT ON数据库设置。但是，数据修改仍然使用锁定来实现事务完整性。以下是文献资料的摘录：

重要的选择事务隔离级别并不影响为保护数据修改而获得的锁。事务总是获得它修改的任何数据的独占锁，并且保持该锁直到事务完成，而不管为该事务设置的隔离级别如何。此外，在READ_COMMITTED隔离级别进行的更新使用所选数据行的更新锁，而快照隔离级别上的更新使用行版本来选择要更新的行。对于读取操作，事务隔离级别主要定义不受其他事务修改影响的保护级别。

如果您将SELECT查询会话更改为使用READ COMMITTED或SNAPSHOT而不是SERIALIZABLE，则将避免此死锁。使用行版本控制实现的所有会话都使用隔离级别，读取器不会阻止或死锁写入器，而visa则相反。只有写入器/写入器块/死锁才可能发生。

除非您计划使用ALLOW_SNAPSHOT_ISOLATION事务隔离级别，否则不需要设置SNAPSHOT数据库选项。