专注,勤学,慎思。戒骄戒躁,谦虚谨慎

just do it

导航

统计

sqlserver默认隔离级别下并发批量update同一张表引起的死锁

 

提到死锁,最最常规的场景之一是Session1 以排它锁的方式锁定A表,请求B表,session2以排它锁的方式锁定B表,请求A表之类的,访问顺序不一致导致死锁的情况
本文通过简化,测试这样一种稍显特殊的场景:对同一张表,并发update其中的多行记录引起的死锁,同时简单分析,对于update操作的加锁步骤
这种场景引起的死锁比较少见,但是并不代表不存在,在某些并发场景下,可能会引起死锁的,应该需要引起重视。

 

测试环境搭建

sqlserver 数据库版本:

Microsoft SQL Server 2014 - 12.0.2269.0 (X64)
Jun 10 2015 03:35:45
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1)

创建测试表并写入测试数据

create table test_deadlock
(
    id int identity(1,1),
    col2 varchar(10),
    col3 varchar(5000),
    createdate datetime
)

alter table test_deadlock
add constraint pk_test_deadlock primary key(id)


create index idx_col2 on test_deadlock(col2)
go


insert into test_deadlock
select concat('A',cast(rand()*1000000 as int)),replicate('B',5000),getdate()
go 1000000

 

死锁重现

两个session,假如是session和session2,分别造sqlserver manager studio查询窗口中执行如下语句,模拟两个session的并发操作

create table #t(col2 varchar(10))

insert into #t
select top 1000 col2 from test_deadlock
order by newid()
go



while 1=1
begin
    update a
    set createdate=getdate() 
    from test_deadlock a inner join #t b on a.col2 = b.col2
end

逻辑就是随机写里临时表中1000行记录,然后依据临时表中的数据更新测试表test_deadlock
分别执行两个session的sql之后,因为#t是随机写入1000行数据,两个session中#t的数据肯定是不完全一样的,然后执行两个session的语句
等待执行一段时间之后(并不一定每次都会出现,或者很快出现,需要多次测试),就会发现其中一个session的执行遇到了死锁,如下

通过sqlserver自带的扩展事件[system_health]查看死锁的详细信息

查看死锁xml的详细信息,非常清楚地显示,两个session在占用了某个key值的U锁之后,相互请求对方占用的U锁的,结果就是死锁

对于两个session wait的key分别是:KEY: 5:72057594045595648 (d813f2171ef9)和KEY: 5:72057594045595648 (872f5c19a82c)
关于key值格式的含义,简单说一下,以KEY: 5:72057594045595648 (872f5c19a82c)为例,5代表数据Id,72057594045595648 代表index的id,(872f5c19a82c)代表key值的内部Id
关于前两者,相对比较简单,通过系统表可以查询出来,如下是当前测试库执行的查询结果,很直观地显示了key值中的信息含义

关于(872f5c19a82c)代表key值的内部Id,可以通过一个未公布的系统函数 %%lockres%% 查看得到,如下,也相对比较清楚。关于 %%lockres%% 不做过多的表述,偏避免偏离主题。

有兴趣了解%%lockres%% 的参考:https://dba.stackexchange.com/questions/106762/how-can-i-convert-a-key-in-a-sql-server-deadlock-report-to-the-value

 

现在可以清楚地得到:
session1 以U锁的方式锁定了一个idx_col2上的索引值 (d813f2171ef9),请求索引值 (872f5c19a82c)上的U锁
session2 以U锁的方式锁定了一个idx_col2上的索引值 (872f5c19a82c),请求索引值(d813f2171ef9)上的U锁
U锁与U锁不兼容,然后发生了死锁。

这里简单分析一下,这两个key值内部Id对应的具体的key值以及两个session的锁定情况。
两个内部Id对应的col2字段分别是A229853和A76383,
也就是说session1 对col2=A229853 key值加U锁,请求col2 = A76383的key值的U锁
session2 对col2=A76383 key值加U锁,请求col2 = A229853 的key值的U锁

那么去具体的session(查询窗口)中的临时表验证一下这两个Id是不是同时存在于两个session的临时表中,是不是这样的。

没有问题,session1和session2中都包含了这两个id,这里默认查询出来的顺序,也刚好相反,更加可以支持上述推断,在执行update的过程中,造成了上述的死锁。

 

死锁原因分析

update的加锁,这里是对1000个col2的值执行更新,内部可以看做是一个过程,即便是使用了索引查找(index seek)
批量update,虽然是一个事物,但是执行的过程,对于目标数据的加锁是一个过程(逐行),这个过程不是隔离的或者说排他性执行的(除非是表级别的排它锁)

粗略地讲,推断其大概过程如下:
依次遍历符合条件的目标数据(#t中的col2与test_deadlock)进行查找,如果找到,加U锁(尚不考虑锁升级为表锁)

伪代码如下

foreach(key in #t)--直接以#t中的col2字段的值,通过索引查找的方式驱动test_deadlock,依次加(U)锁
{
  if(key==test_deadlock.col2)
  {
    updlock test_deadlock.col2
  }
}

加锁,这里是逐行对test_deadlock中的col2 key加U锁是一个过程,而不是一瞬间。一旦两个session加锁目标存在交集,并且对加锁的key值加锁顺序不一致,就潜在发生死锁的可能性。
比如session1 先对key = A229853 的值加U锁,再视图key = A229853 加U锁
session2先对key = A229853 的值加U锁,再试图key = A229853 加U锁,死锁就因此而产生
这里的update语句,内部是一个事物没错,但是需要个事物区分来看,当前update加的锁是一个key锁,而不是表锁,既然是key锁,需要逐个查找然后加锁,而不是一次性加锁
这就是当前这种场景产生死锁的原因。

该死锁产生的条件
1,存在比较大的并发量,或者是做并发压力测试
2,并发session update的目标数据存在交集
3,服务器资源使用率比较高或者负载比较重的时候更容易出现

 

如何解决

上述分析原因是一次对不同的key值加U锁,不同session加锁目标存在交集,且加锁顺序不一致引起的,在read committed或者可重复度隔离级别,都无法解决上述家锁冲突问题

1,从逻辑key值加锁顺序入手:

问题的本质在于,并发session对目标数据加锁目标存在交集,且对加锁目标的加锁(key值)顺序不一致,如果使并发session对加锁目标(key值)加锁顺序一致,也就不会出现死锁的情况了。
如果按照对key值顺序的方式加锁(通过在key值上创建cluster索引),
可以将上面key值的随机访问变为顺序访问(table scan变为cluster index scan),只会出现相互阻塞,而不是死锁,想一想为什么……
这里通过对#t的目标值字段,创建一个索引,再经并发测试,不会出现死锁.
但是这种方式,并上不是最佳的,因为执行计划不会永远只有一种,
这里主观上要求一定是#t表驱动目标表test_deadlock,面对更加复杂的实际情形,如何保证?难道需要再次加强制索引+驱动顺序提示?(事实证明,这种方式极其不可靠)

insert into #t
select top 1000 col2 from test_deadlock
order by newid()

create cluster index idx_col2 on #t(col2)
go

while 1=1
begin
    update a
    set createdate=getdate() 
    from test_deadlock a   inner join #t b on a.col2 = b.col2
end

2,从锁定方式入手:

可序列化隔离级别,或者直接对update的目标表加表级别锁解决
事实上经过测试,出乎意料的是,可序列化隔离级别依旧解决不了上述加锁冲突,如下,当然,序列化隔离级别下,死锁类型跟默认隔离级别下并不完全相同,是RangeS-U之间的冲突
序列化可能造成的死锁,也有大把的例子,这里不继续扯了,参考https://stackoverflow.com/questions/27347730/serializable-transaction-deadlockhttps://stackoverflow.com/questions/39029573/why-does-a-serializable-isolation-level-lead-to-deadlock-and-concurrency-issues

经测试,直接加表级别锁,可以解决上述死锁问题,参考如下

while 1=1
begin
    update a
    set createdate=getdate() 
    from test_deadlock a with(updlock,tablock) inner join #t b on a.col2 = b.col2
end

另外,如果其他办法,也未尝不可,从应用程序的角度,可以使用类似于单例模式,从发起端开始排队,或者将目标数据写入队列的方式,依次排队打入数据的方式执行,都是可以避免死锁的。

 

最后
这种死锁,并不会轻易生成,但它是确确实实存在的,或者说是潜在的,笔者根据实际场景在本地反复做测试,中间也遇到一些问题
1,基于当前测试方式和场景,测试数据量要足够大,设计case的时候,要避免自动的锁升级造成测试干扰,避免某些写法让#t中生成的数据有序,都会重现这种场景
2,如果想从默认扩展事件system_health的ring_buffer中查看死锁信息,类似本文,需要对[system_health]默认的扩展事件加大ring_buffer的max_events_limit和max_memory。
  至于为什么,参考这个:https://www.cnblogs.com/wy123/p/9055731.html
3,对于高性能的服务器,比较难以重现这种场景,因为每个session都执行的相对较快
4,测试库如果是完整恢复模式,小心撑爆事物日志或者磁盘空间

 

该死锁产生场景的扩展

对于类似的死锁产生场景,与并发批量update的逻辑一样,在并发批量做delete的时候也会出现死锁,并且已经在生产环境发现过。
并发批量insert,会不会产生类似的死锁,如果产生了,又如何解决,继续测试。
可能会死锁产生的场景,还是超出了预料……


并发insert的造成的死锁场景,也可以间接模拟出来,通过将批量insert拆分成多句单个的insert,来模拟key值加锁顺序冲突造成的死锁死锁
如下代码创建一个测试表

create table test_deadlock2
(
    id int identity(1,1),
    col2 int,
    createdate datetime
)

alter table test_deadlock2
add constraint pk_test_deadlock2 primary key(id)

--注意,这里是的col2是一个唯一索引
create unique index idx_col2 on test_deadlock2(col2)

--预先写入测试数据
insert into test_deadlock2 values (0,getdate()),(100,getdate()),(200,getdate()),(300,getdate())

这里模式的死锁方式并不是偶然的,是必然的,需要了解insert的加锁机制

第一步,session1中,开事物,执行第一句insert语句

第二步,session2中,开事物,执行第一句insert语句

第三步,session1中执行第二句insert,被阻塞

第四部,session2中执行第二句insert语句,session2作为死锁的牺牲品,session1顺利完成

最后,session2死锁应运而生,session1 正常执行完成,至于问题的原因,跟上面批量update造成的死锁,基本上完全一样

只不过这里把批量insert(类似于insert into table select col from #t)转换为单行的insert,使得问题更容易出现。

 

仅测试本文的场景,笔者个人的机器是12GB内存,8核心I7 CPU,测试过程,机器没有开其他应用程序,已经巨卡无比,内存几乎完全占满(当然CPU没有太大压力),重启数据库服务之后,瞬间轻松。

 

posted on 2019-05-14 23:38 MSSQL123 阅读(...) 评论(...) 编辑 收藏