Sql server 死锁：钥匙锁资源列表中的属性模式与所有者列表模式不同

我最近一直在处理我们应用程序中的一些死锁情况，并且有一个新的案例对我来说似乎很奇怪。错误日志显示了这一点（没有执行堆栈，我相信这在此时并不重要）：

锁发生在一个表中同一聚集索引中的一个键上。让我有点困惑的是资源列表中最后一行的模式

它显示：mode=U，而相应所有者列表中的所有者显示：mode=S

我该怎么读呢？这两种模式通常是相同的。这些模式有什么不同？

这段引语可能会提供一个解释：

为了避免这种潜在的死锁问题，使用了更新（U）锁。 一次只能有一个事务获取资源的更新（U）锁 时间如果事务修改资源，则更新（U）锁为 已转换为独占（X）锁。否则，将转换锁 到共享模式锁

因此，请求共享锁的一个事务（可能是第一个）最终持有更新锁。更新锁仅为事务提供了一个选项，如果它想进行更新，则可以将其转换为独占锁

---

如果两个事务读取然后写入同一行，则此机制会有所帮助。在您的情况下，有两行在起作用。第一个事务在A行上有一个独占锁，正在等待转换为B行上的独占锁。第二个事务在B行上有一个共享锁，这实际上是一个更新锁，它正在等待A行上的独占锁。

我将其解释为，

process47bdc8

在该资源上有一个

U

锁，正在等待将其转换为

X

锁，但不能，因为

process84db88

已经有了

s

锁

---

S

锁和

U

锁。

你可能是对的，马丁。ProcessProcess84DB88只选择一些数据，它不在事务中运行，而OurTable作为联接在该查询中。由于它是同一索引上的锁，您知道SQL Server是如何获取其锁的吗？它能否从select查询中获得一个锁，但在同一查询请求的第二个锁上失败？不应获取所有锁或不获取任何锁。对我来说，它似乎是这样工作的：请求锁1，请求允许前进一步，请求锁2，请求拒绝你必须等待锁2，但仍然保持锁1。这是不可能的，对吗？@John-是在

readcommitted

读取数据时，它将单独取出行

S

锁，并在读取数据后立即释放它们。您可以使用SQL Server事件探查器跟踪获取和释放的锁事件，以查看这一点（在开发服务器上，因为此跟踪可以生成大量数据）@John-BTW：如果您在事件探查器中进行跟踪，您可能会看到行

S

锁并不总是被取出。死锁的发生是因为两个进程互相等待了一定的时间，对吗？因此，如果process1在key1上获得锁，那么它应该在读取数据后释放该锁？然后，如果process2持有对key2的锁，并且process1请求对key2的锁，process2可以等到process1读取key1上的数据并获取自己的锁，完成其更新/插入..然后释放所有锁，然后process1可以继续读取key2上的数据吗？我希望你能理解我在这里写的东西：）@John-你是在问为什么死锁不能通过

process84db88

简单地释放它的S锁来解决，因为它已经读取了数据？其实不太清楚。好问题！在探查器中跟踪锁事件应该可以对此有所帮助。

deadlock-list
  deadlock victim=process84db88
   process-list
    process id=process84db88 taskpriority=0 logused=0 waitresource=KEY: 11:72057594409844736 (8194443284a0) waittime=4685 ownerId=3632385974 transactionname=SELECT lasttranstarted=2011-12-07T16:21:16.287 XDES=0x32f68fca0 lockMode=S schedulerid=6 kpid=6392 status=suspended spid=93 sbid=0 ecid=0 priority=0 trancount=0 lastbatchstarted=2011-12-07T16:21:16.287 lastbatchcompleted=2011-12-07T16:21:16.287 clientapp=.Net SqlClient Data Provider hostname=DE-1809 hostpid=4156 loginname=XXX isolationlevel=read committed (2) xactid=3632385974 currentdb=11 lockTimeout=4294967295 clientoption1=671088672 clientoption2=128056
     executionStack
      ........   
    process id=process47bdc8 taskpriority=0 logused=240604 waitresource=KEY: 11:72057594409844736 (829df5d1e88e) waittime=4681 ownerId=3632397262 transactionname=UPDATE lasttranstarted=2011-12-07T16:21:26.100 XDES=0x2f00b93c0 lockMode=X schedulerid=1 kpid=6568 status=suspended spid=88 sbid=0 ecid=0 priority=0 trancount=2 lastbatchstarted=2011-12-07T16:21:25.640 lastbatchcompleted=2011-12-07T16:21:25.640 clientapp=.Net SqlClient Data Provider hostname=DE-1809 hostpid=4156 loginname=XXX isolationlevel=read committed (2) xactid=3632397262 currentdb=11 lockTimeout=4294967295 clientoption1=673316896 clientoption2=128056
     executionStack
      .........  
   resource-list
    keylock hobtid=72057594409844736 dbid=11 objectname=dbo.OurTable indexname=PK_OurTable id=lock1d9aa0b00 mode=X associatedObjectId=72057594409844736
     owner-list
      owner id=process47bdc8 mode=X
     waiter-list
      waiter id=process84db88 mode=S requestType=wait
    keylock hobtid=72057594409844736 dbid=11 objectname=dbo.OurTable indexname=PK_OurTable id=lock1a56cb580 mode=U associatedObjectId=72057594409844736
     owner-list
      owner id=process84db88 mode=S
     waiter-list
      waiter id=process47bdc8 mode=X requestType=convert