理解和解决Server 2008 R2中的死锁

Question

我正在努力找出下面显示的死锁图可能出了什么问题：

我几乎每10分钟就会收到类似于上面提到的死锁的警报，这只是查询的变化，死锁的操作保持不变：

**Wait Resource Page:11:11:...2820**
Lock Type:  Page
Own/Wait: Own
Mode: X
SPID: 1568
ECID: 0
Sql: 
    update access 
    set accessdate=accessdate  where userid= 'ABC.DEF' and companyid= '12' 
    and databasename= 'XYZ' and internetaddress= 'KASQL-Tcp#10' 
    and sessioncntr=12 and tstamp <= 0x0000000000sw123
Lock Type: Page
Own/Wait: Wait
Mode: U
SPID: 1120
ECID: 0
Sql: 
    delete access where userid= 'ADAm.Smith' and companyid= '23' 
    and databasename= 'XYZ' and internetaddress= 'KASDER-Tcp#8' 
    and sessioncntr=23

**Wait Resource Page:11:11:...2830**
Lock Type: Page
Own/Wait: Own
Mode: X
SPID: 1120
ECID: 0
Sql: 
    delete access where userid= 'ADAm.Smith' and companyid= '23' 
    and databasename= 'XYZ' and internetaddress= 'KASDER-Tcp#8' 
    and sessioncntr=23  
Lock Type: Page
Own/Wait: Wait
Mode: U
SPID: 1568
ECID: 0
Sql: 
    update access 
    set accessdate=accessdate  where userid= 'ABC.DEF' and companyid= '12' 
    and databasename= 'XYZ' and internetaddress= 'KASQL-Tcp#10' 
    and sessioncntr=12 and tstamp <= 0x0000000000sw123

我看过碎片&任何缺少的索引，但这对数据库xyz都有好处，正如上面的查询所提到的那样！

注意:死锁图中提到的DBID表示dbid 11，这与查询中的e( XYZ )不同，因此dbid11实际上是另一个数据库'DBCapse‘。

请提供任何能帮助我解决和理解这一僵局情况的投入。

Answer 1

看起来像一个事务中的多个语句。一行是第一个事务的第一个语句和第二个事务的第二个语句的目标。反之亦然:第一个事务的第二个语句和第二个事务的第一个语句以同一行为目标。

有理由使用多语句事务处理吗？

如果是这样的话，您是否可以对事务中的语句进行“排序”，以便它们总是以预定义的顺序影响行？在带有id identity键的行中，如果连续语句会影响更高的id事务，则冲突的可能性将大大降低。