With a system health session, you can keep track of SQL

Server deadlocks.
Because of the error notice, the database administrator decided to look into the deadlock issues. The error
message clearly indicated a deadlock situation. As a first step, he chose to look for deadlocks in the system
health session. The transaction (Process ID XX) was chosen as the deadlock victim because it was blocked on
lock resources with another process. Run the transaction again. The system health session is SQL Server's
default extended event session, and it starts immediately when the database engine starts. The system
health session gathers a variety of system data, including deadlock information. The following query reads
the system health session's.xel file and displays details about any deadlock issues that occurred. The system
health session can be an excellent place to start when trying to figure out what's causing the deadlock. The
query below can be used to identify deadlock issues that are detected by the system health session.

Using Extended Events, you can keep track of SQL

Server deadlocks.
The data gathered by the system health session provided some indications to the database administrator
regarding the deadlock problem. However, he believes that because of file size restrictions, the system health
session only shows the most recent events, and hence cannot be relied upon to detect all SQL Server
deadlocks. As a result, he decided to create a new extended event session to record all of the deadlocks.
Extended Event is a SQL Server system monitoring tool that collects events and system information. We can
also capture deadlock information from SQL Server using the XEvent. To begin, open SQL Server Management
Studio and go to the Session folder in the Management folder. Select New Session by right-clicking on the
Sessions folder. We'll give the session a name and check the Start the event session immediately after the
session creation checkbox on the New Session screen, which means the session will begin soon once the
creation process is completed. The events we want to capture are selected on the Event tab. We'll pick the
following activities for this session:

 database_xml_deadlock_report
 xml_deadlock_report
 xml_deadlock_report_filtered

We will click the Configure button and select global events that will be captured with the events:

 client app name

 client connection id
 client hostname
 database id
 database name
 nt username
 username
 sql text
 username

Deadlocks in SQL Server are investigated and resolved.
In this part, we will first simulate a deadlock situation before attempting to determine the root cause of the
stalemate. We run SQLQueryStress with the following parameters and wait for the query execution process
to complete. We need to look at the extended event session, which was built to collect the deadlock events,
to learn more about the problem. Expand the MonitorDeadlock session and right-click on the target node,
then choose View Target Data from the context menu. In the right pane, the captured deadlocks will be
displayed. The SPID 65 (victim) has gained an intent exclusive lock and wishes to place an update lock on the
TestTblCounter table, according to the deadlock graph. Because of the TABLOCKX suggestion, the SPID 64 has
an exclusive lock on the TestTblCounter and wishes to place an exclusive lock on the same table. The
TABLOCKX hint allows you to place an exclusive lock on the table until the select statement or transaction is
finished. The TABLOCKX hint has the downside of decreasing concurrency, which increases locking time.
When we decided to use it, we need to take account of the lock and contention problems. Particularly for this
scenario, this hint usage logic is improper. When we revisit the query, the update statement alters some
rows, and the select statement collects the same updated rows, but because of the TABLOCKX hint, it places
an exclusive lock on the entire table until it completes. The line where the value is assigned to the variable is
The data assignment to the variable is done at random, making this query's most useless element. Why do
we need to apply an exclusive lock to all of the table's rows in order to get the most recently changed or
added row? As a result, we can delete the TABLOCKX hint from the query, which creates deadlocks. At the
same time, we can utilize the OUTPUT clause to get the last inserted or changed row value.

Conclusion
In this post, we'll go through SQL Server deadlocks and then look at a real-life scenario with a development
team. Understanding and interpreting the stalemate report and graph correctly is critical to generating a
solution. Otherwise, determining the root of the problem will be quite difficult. Recall the steps in the
solution:

 Check the system health session for deadlocks

 Create an extended event session to capture the deadlocks
 Analyze the deadlock reports and graphs to figure out the problem
 If it is possible to make improvements or changing the queries involved in the deadlock