共计 1787 个字符,预计需要花费 5 分钟才能阅读完成。
某现场报一个 SQL 死锁,于是开启了 1222 跟踪:
dbcc traceon(1222,-1)
一段时间之后拷贝 ERROR 文件查找相关信息,比较有用的摘录出来如下:
语句一:
select
study_iuid,station_aet,modality,accession_no,patient_fk,item_attrs,start_datetime
from
worklist w
WITH
(readpast), mwl_item m
where
w.TAG_STUDY_INSTANCE_UID=m.study_iuid
and
isread=
'1'
and
(TAG_SPS_STATUS
is
null
or
TAG_SPS_STATUS=
'SCHEDULED'
or
TAG_SPS_STATUS=
'Discontinued'
)
and
TAG_SPS_START_DATE
between
@P0
and
@P1
and
not
exists (
select
1
from
mpps b
where
b.study_iuid=m.study_iuid)
语句二:
INSERT
INTO
mwl_item (created_time, updated_time, sps_id, start_datetime, station_aet, station_name, modality, perf_physician, perf_phys_fn_sx, perf_phys_gn_sx, perf_phys_i_name, perf_phys_p_name, req_proc_id, accession_no, study_iuid, item_attrs, sps_status, patient_fk)
VALUES
(@P0, @P1, @P2, @P3, @P4, @P5, @P6, @P7, @P8, @P9, @P10, @P11, @P12, @P13, @P14, @P15, @P16, @P17);
相关的死锁资源如下:
resource-list
pagelock fileid=1 pageid=6996 dbid=8 objectname=Worklist.dbo.mwl_item id=lock19825c100 mode=IX associatedObjectId=72057594039697408
owner-list
owner id=process984d048 mode=IX
waiter-list
waiter id=process60e9708 mode=S requestType=wait
pagelock fileid=1 pageid=11086 dbid=8 objectname=Worklist.dbo.mwl_item id=lock1b087b100 mode=S associatedObjectId=72057594039697408
owner-list
owner id=process60e9708 mode=S
waiter-list
waiter id=process984d048 mode=IX requestType=wait
可以明显的看到是 select 语句与 insert 语句产生了死锁,争用的资源分别 6996 和 11086 这两个 page,这里比较奇怪因为 sqlserver 在默认隔离级别下,select 操作会迅速释放页上的 S 锁,因此不存在形成死锁的基础 – 不可剥夺条件。
但其实这里是一种形成死锁的典型条件,参考宋大神的一幅图这里:– 由书签查找产生的死锁。
其原理为:
1. 由最初的 update 语句产生数据页 A 的 IX 锁,更新完毕后要请求索引页 B 的 IX 锁以便更新索引,但此时 B 页上已有与 IX 不兼容的 S 锁。
2. 而 select 语句在索引页 B 上加了 S 锁后,正要通过书签查找获取数据页 A 的数据,要获取 A 页就要在 A 页上暂时加 S 锁,但 A 页又被 update 语句加了不兼容的 IX 锁,因此两个进程形成环路等待 —- 死锁。
根据死锁的产生原理决定进行以下优化:
1. 优化 select 语句使其尽快完成以减少死锁频率。
2. 对 select 语句使用 nolock 选项以避免死锁问题。
3. 通知开发优化相关代码的执行顺序来避免死锁问题。
最终优化了 select 语句,其他两条交给开发做修改。
本文永久更新链接地址 :http://www.linuxidc.com/Linux/2017-06/144604.htm
正文完
星哥玩云-微信公众号