Question

我正在帮助解决使用SQL Server 2005的.NET应用程序中的一些死锁问题。我从下面的跟踪中获取了XML数据。

在提交事务隔离级别时，PK_Exp_Experience_PriorFirm上的RangeX-X锁定真正让我感到困惑。

我读过的所有内容都表明您只使用事务隔离级别“可序列化”获得了键范围锁定。到目前为止，我在应用程序中找不到任何位置，我们将隔离级别设置为read committed之外的任何其他位置，下面的XML也表明我们正在使用read committed。

但是如果我们使用read-committed，我不明白跟踪如何显示有一个键范围锁定。有没有人对如何发生这种情况有所了解？

<deadlock-list>
  <deadlock victim="processc2f438">
    <process-list>
      <process id="processc2f438" taskpriority="0" logused="13488" waitresource="KEY: 120:72057594583646208 (8201498b6efe)" waittime="484" ownerId="693258089" transactionname="user_transaction" lasttranstarted="2009-01-06T16:33:27.817" XDES="0xa71ce370" lockMode="U" schedulerid="1" kpid="9112" status="suspended" spid="53" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2009-01-06T16:33:27.863" lastbatchcompleted="2009-01-06T16:33:27.863" clientapp=".Net SqlClient Data Provider" hostname="CHQAPT3" hostpid="6464" loginname="AppUser" isolationlevel="read committed (2)" xactid="693258089" currentdb="120" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
        <executionStack>
          <frame procname="adhoc" line="1" stmtstart="108" sqlhandle="0x0200000015d9962978fc6206b09e4c872150511b455e8923">
            UPDATE Exp_Experience_PriorFirm SET RelatedGuid = @newGuid WHERE RelatedGuid = @oldGuid
          </frame>
          <frame procname="mssqlsystemresource.sys.sp_executesql" line="1" sqlhandle="0x0400ff7fbe80662601000000000000000000000000000000">
            sp_executesql
          </frame>
          <frame procname="MyDb.dbo.Contact_MergeRelationships" line="74" stmtstart="4754" stmtend="4976" sqlhandle="0x0300780036a608461ed8af00669b00000100000000000000">
            EXEC sp_executesql @sql,
            N'@oldGuid uniqueidentifier, @newGuid uniqueidentifier',
            @oldGuid, @newGuid
          </frame>
          <frame procname="MyDb.dbo.Contact_Company_MergeRelationships" line="8" stmtstart="312" sqlhandle="0x03007800b271a129c8ccaf00669b00000100000000000000">
            EXEC Contact_MergeRelationships @oldGuid, @newGuid, 'Contact_Company', @excludedTableNames
          </frame>
        </executionStack>
        <inputbuf>
          Proc [Database Id = 120 Object Id = 698446258]
        </inputbuf>
      </process>
      <process id="processeb5d68" taskpriority="0" logused="14212" waitresource="KEY: 120:72057594594066432 (7c02a3a5890e)" waittime="2312" ownerId="693243114" transactionname="user_transaction" lasttranstarted="2009-01-06T16:33:20.957" XDES="0x8cdb9450" lockMode="S" schedulerid="2" kpid="9000" status="suspended" spid="73" sbid="0" ecid="0" priority="0" transcount="2" lastbatchstarted="2009-01-06T16:33:29.770" lastbatchcompleted="2009-01-06T16:33:29.770" clientapp=".Net SqlClient Data Provider" hostname="CHQAPT3" hostpid="6464" loginname="AppUser" isolationlevel="read committed (2)" xactid="693243114" currentdb="120" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128056">
        <executionStack>
          <frame procname="MyDb.dbo.Contact_Company_Delete" line="27" stmtstart="1128" sqlhandle="0x03007800b0e5761877cbaf00669b00000100000000000000">
            DELETE FROM Contact WHERE GUID = @Guid;
          </frame>
        </executionStack>
        <inputbuf>
          Proc [Database Id = 120 Object Id = 410445232]
        </inputbuf>
      </process>
    </process-list>
    <resource-list>
      <keylock hobtid="72057594583646208" dbid="120" objectname="MyDb.dbo.Exp_Experience_PriorFirm" indexname="PK_Exp_Experience_PriorFirm" id="lockd1d43f80" mode="RangeX-X" associatedObjectId="72057594583646208">
        <owner-list>
          <owner id="processeb5d68" mode="RangeX-X"/>
        </owner-list>
        <waiter-list>
          <waiter id="processc2f438" mode="U" requestType="wait"/>
        </waiter-list>
      </keylock>
      <keylock hobtid="72057594594066432" dbid="120" objectname="MyDb.dbo.Contact_PersonCompanyLocation" indexname="PK_Contact_PersonCompanyLocation" id="lockd20c4380" mode="X" associatedObjectId="72057594594066432">
        <owner-list>
          <owner id="processc2f438" mode="X"/>
        </owner-list>
        <waiter-list>
          <waiter id="processeb5d68" mode="S" requestType="wait"/>
        </waiter-list>
      </keylock>
    </resource-list>
  </deadlock>
</deadlock-list>

Answer 1

PK_Exp_Experience_PriorFirm上的RangeX-X锁被作为级联删除的一部分。

SQL Server会自动将隔离级别升级为可序列化以进行某些操作，例如级联删除。

这里有更详细的描述：Conor vs. Isolation Level Upgrade on UPDATE/DELETE Cascading RI。

Answer 2

您正在使用READ COMMITED，正如您所期望的那样。

如果UPDATE在聚簇索引上获取了一个eXclusive键锁并修改了一行，并且该锁阻止了对聚簇索引的SELECT书签查找，则会发生这样的死锁。

通常可以通过创建覆盖非聚集索引来消除此类锁定。

将NOLOCK提示添加到有问题的SELECT语句是一种解决方案，前提是您可以容忍未提交的读取。

您可以使用的另一个选项是为数据库设置READ_COMMITED_SNAPSHOT ON。这改变了SELECT语句读取提交数据的方式;他们不是采用共享锁，而是读取由SELECT语句开头的事务更改的任何数据的先前版本（快照）。这不是完全免费的;费用增加tempDB中的活动。 [在READ COMMITED SNAPSHOT模式下，触发器也有可能出现问题。]

Answer 3

对此的另一个常见解释可能与IGNORE_DUP_KEY选项设置为ON的UNIQUE索引有关。

From BOL - 此选项指定插入操作尝试将重复键值插入唯一索引时的错误响应。 IGNORE_DUP_KEY选项仅适用于创建或重建索引后的插入操作。执行CREATE INDEX，ALTER INDEX或UPDATE时，该选项无效。默认为OFF。

打开将重复键值插入唯一索引时，将出现警告消息。只有违反唯一性约束的行才会失败。

关闭将重复键值插入唯一索引时，将出现错误消息。整个INSERT操作将被回滚。

这里没有提到的是，当启用此选项时，INSERTS期间会强制执行SERIALIZABLE隔离。我个人没有理解这样做的固有要求，因为一些插入的行可能会被丢弃而没有别的，但它就是它的本质。将SQL开发团队排队到此处... ...

这种行为很容易证明;

首先使用典型的PK创建一个新表：

CREATE TABLE [dbo].[Test_RC_TIL_RangeLocks]( [RID] [int] IDENTITY(1,1) NOT NULL, [Col1] [int] NOT NULL, [Col2] [int] NOT NULL, [Col3] [int] NOT NULL ) ON [PRIMARY]

接下来我们要在Col1和Col2上添加一个UNIQUE索引，IGNORE_DUP_KEY ON：

CREATE UNIQUE NONCLUSTERED INDEX [UIX_Test_RC_TIL_RangeLocks] ON [dbo].[Test_RC_TIL_RangeLocks]( [Col1] ASC, [Col2] ASC )WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = ON, --<<**THE OFFENDER**>> DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]

接下来我们将添加5行，看看会发生什么......

SET TRANSACTION ISOLATION LEVEL READ COMMITTED DECLARE @C int SELECT @C=5 BEGIN TRANSACTION WHILE @C>0 BEGIN INSERT Test_RC_TIL_RangeLocks(Col1,Col2,Col3) VALUES (@C,@C+1,2*@C + 100) SET @C=@C-1 END SELECT * FROM Test_RC_TIL_RangeLocks EXEC sp_lock @@SPID COMMIT

正如预期的那样，我们增加了五行：

RID Col1 Col2 Col3 1 5 6 110 2 4 5 108 3 3 4 106 4 2 3 104 5 1 2 102

我们感兴趣的锁是：

sid ObjId IndId Type Resource Mode 53 0 0 DB S 53 0 0 DB S 53 402100473 1 KEY (8194443284a0) X 53 402100473 2 KEY (550e0a2a4b96) RangeX-X 53 402100473 2 KEY (ffffffffffff) RangeS-U 53 1131151075 0 TAB IS 53 402100473 1 PAG 1:744 IX 53 402100473 2 PAG 1:748 IX 53 402100473 1 KEY (98ec012aa510) X 53 402100473 1 KEY (a0c936a3c965) X 53 402100473 2 KEY (ec04ac4bee1f) RangeX-X 53 402100473 0 TAB IX 53 402100473 2 KEY (0207a0a08e23) RangeX-X 53 402100473 2 KEY (7112ec63c430) RangeX-X 53 402100473 1 KEY (59855d342c69) X 53 402100473 1 KEY (61a06abd401c) X 53 338100245 0 TAB IX

啊，在简单插入的READ COMMITTED隔离级别上调用可怕的SERIALIZABLE键范围锁！

所以当BOL说; 在进行键范围锁定之前，必须满足以下条件：

•事务隔离级别必须设置为SERIALIZABLE。

请记住，这并非总是如此......

P.S。作为设计说明，盲目地消除可能具有唯一行值的重复键通常是不好的做法。更好的做法是确保您没有尝试在INSERT语句中插入重复的键...

干杯...

Answer 4

根据SQL Docs，不知何故，您的事务（或其他事务）在可序列化的级别上运行。

密钥范围锁定的文档here。第一句话是：

使用可序列化事务隔离级别时，键范围锁保护隐式包含在Transact-SQL语句读取的记录集中的行范围。

SQL Server 2005：读取提交事务隔离级别中的键范围锁定？

4 个答案: