SQL Server Deadlock Case Study

Abstract: Overview When an application frequently reads and writes a table or resource, it is prone to deadlock. When a deadlock occurs, SQL Server chooses to terminate one of the transactions and sends the following error message to the client that initiated the transaction. Error Message: Msg 1205, Level 13, State 47, Line 1Transaction (Process ID 53) was deadlocked on lock resources with an
overview
When an application reads and writes a table or resource frequently, deadlock is easy to occur. When a deadlock occurs, SQL Server chooses to terminate one of the transactions and sends the following error message to the client that initiated the transaction.
Error Message:
Msg 1205, Level 13, State 47, Line 1Transaction (Process ID 53) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Collect deadlock information
If it is self-built on ECS instance of SQL Server, luckily, there is a convenient way to enable trace flag 1222 to record deadlocks in the error log in real time.
DBCC TRACEON(1222,-1)
For the collection method of RDS SQL Server deadlock information, there is a detailed description in the RDS for SQL Server deadlock processing method, such as sys.sysprocesses and SQL Server Profiler, the detailed steps are not here. Repeatedly.
Deadlock log analysis
Generally speaking, the deadlock logs recorded by SQL Server Profiler and 1222 are comprehensive. SQL Server Profiler collects deadlock logs, which consumes high performance, but automatically displays deadlock maps for easy analysis.
For 1222, the deadlock information is collected in the error log, which can be turned on all the time. It will only be recorded in the log when a deadlock occurs, which has less impact on performance, but the analysis is slightly more complicated. The analysis process of the error log is as follows:
The main time period when the deadlock occurs is from 10:00 to 11:38 on June 3, and the deadlock process occurred at 10:00:06.16. The lock and resource information is as follows:
Process process89a9a6748 is in resource pageid =227126 holds the IX lock. At this time, process43c824748 wants to apply for the U lock on the page and is blocked. At the same time, process43c824748 holds a U lock on pageid=11768. At this time, process89a9a6748 needs to apply for a U lock on the page and is blocked. At this point, the two processes block each other, forming a deadlock.
Deadlock resource resource 1 resource 2
resource type pagelock pagelock
specific content pageid=11768 dbid=37 pageid=227126 dbid=37
holding resource process process43c824748 process89a9a6748
waiting for resource process process89a9a6748 process43c824748
process process89a9a6748 execute statement
UPDATE C SET TaskTitle=T.TaskTitle FROM WF .C***Task AS C
INNER JOIN @complateTask AS T
ON T.TaskID=C.TaskID
EXEC WF.PROC_UpdateTask_Opin @INTRANSACTION,@processID,@isClearUnread,@task,@complateTask,@opin
process process43c824748 execute statement
UPDATE C SET TaskTitle=T.TaskTitle FROM WF.***Task AS C
INNER JOIN @complateTask AS T
ON T.TaskID=C.TaskID
EXEC WF.PROC_**Task_Opin @INTRANSACTION,@processID,@isClearUnread,@task,@complateTask,@opin
Solution opinion
According to the observation table structure and statement execution plan and other information , it is recommended to add a non-clustered index on the TaskID field of the table WF.CompletedTask to improve the update execution speed and reduce the holding time of the U lock.