Question: How can I capture information about a deadlock on my Amazon RDS DB instance running SQL Server?

I have an Amazon Relational Database Service (Amazon RDS) DB instance that runs Microsoft SQL Server. I want to get more details about a deadlock on my RDS DB instance.

ResolutionA deadlock is encountered when two or more sessions, each with a resource locked, attempt to access the other session’s locked resource. The result is a "circular chain". When this happens, none of the sessions will continue to run until:One of the sessions releases its locks.Which allows the other session to access the locked resource.SQL Server's deadlock detector resolves this situation by ending one of the sessions using a resource-based or cost-based mechanism. Then, the detector rolls back any modifications related to this session. After one of the sessions is ended, the locks held by the session are released, and the other session is allowed to continue. For more information, see Microsoft documentation for Deadlocks.You can capture information about a deadlock event on your DB instance using one of the following ways.Activate trace flagsYou can activate the deadlock trace flags (1204,1222). Trace flags are used to customize SQL Server behaviors, such as additional monitoring by capturing deadlock information in the SQL Server error logs.Trace flag 1204 provides deadlock information about each of the nodes involved in the deadlock.Trace flag 1222 provides more detailed deadlock information than trace flag 1204 in XML format.You can activate both trace flags to get two different representations for each deadlock event. To set this up, see How can I receive a notification when a deadlock event occurs on my Amazon RDS SQL Server DB instance? After the trace flags are activated, you can review the SQL Server error logs for more information on the deadlock event.Use the system_health sessionExtended events is a lightweight performance monitoring system that helps you to collect data to monitor and troubleshoot problems in SQL Server. The system_health extended events session is included in SQL Server and activated by default. The session starts automatically when your SQL Server database engine starts and collects basic server health information. You can use this information to troubleshoot performance issues and monitor deadlocks within your database engine.The system_health extended event session uses two targets, event file and ring buffer, to store the data.By default, the size of each individual file is 5 MB and the number of maximum rollover files is four. This adds up to 20 MB of system_health extended event data. For SQL Server 2016, 2017, and 2019, the size of individual files is 100 MB and the maximum number of files is increased to 10. This adds up to 1 GB of data.The ring buffer is a special data structure in the memory that stores data on a first-in-first-out (FIFO) basis. The target memory of the ring buffer can’t exceed 4 MB in Amazon RDS for SQL Server. Therefore, on a busy instance, the system_health session might rotate events.Use the system_health session to retrieve information about a deadlock on your DB instance with either Microsoft SQL Server Management Studio (SSMS) or Transact-SQL (T-SQL).Do the following to retrieve deadlock information using SSMS:Open SSMS.On Object Explorer, choose Management, and then choose Extended Events.Choose Sessions.Find system_health session, and then choose (double-click) package0.event_file to open the extended event file.After the file contents have loaded, on the SSMS menu, choose Extended Events.Choose Filters.In the Filter window, do the following:For Field, select name.For Operator, select Contains.For Value, select deadlock.Choose OK. You can view the events with deadlocks.Choose the event that you want to view, and then choose the Deadlock tab to view the graph.-or-Do the following to retrieve deadlock information using T-SQL:1.    Run a query similar to the following to view the list of deadlocks:SELECT XEvent.query('(event/data/value/deadlock)[1]') AS DeadlockGraphFROM (    SELECT XEvent.query('.') AS XEvent    FROM (        SELECT CAST(target_data AS XML) AS TargetData        FROM sys.dm_xe_session_targets st        INNER JOIN sys.dm_xe_sessions s         ON s.address = st.event_session_address        WHERE s.NAME = 'system_health'        AND st.target_name = 'ring_buffer'        ) AS DataCROSS APPLY TargetData.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(XEvent)) AS source;2.    Choose the deadlock XML output to open the XML file in a new window.3.    Save the XML using the .xdl file extension. This converts the XML into a graphical format.4.    Navigate to the file location, and then open the .xdl file in SSMS to view the deadlock graph.You can run the T-SQL query to retrieve deadlock information from ring_buffer. The ring_buffer target holds event data in memory. This information is available only as long as the instance isn't rebooted. When you reboot, this information is purged.Use an xml_deadlock_report extended events sessionYou can create an extended event session by selecting the xml_deadlock_report event to capture deadlocks. Selecting an event file as the target saves the events to the file. This file can be analyzed in the future. To create an extended event session, you can use either SSMS or T-SQL. After the session is created, you can retrieve information about a deadlock on your DB instance. You can do this using either SSMS or T-SQL.Do the following to create an extended event session using SSMS:Open SSMS.On Object Explorer, Choose Management, and then choose Extended Events.Choose (right-click) Sessions, and then choose New Session Wizard.For Session name, enter the name of your session, and then choose Next.On the Choose Template page, select Do not use a template.Choose Next to open the New Session Wizard page.From Event library, select xml_deadlock_report, and then choose Next.In the Capture Global Fields page, select values that are common to all events.Note: Select sql_text field to see the query that caused the deadlock.Choose Next.In the Set Session Event Filters page, create event filters to limit the data that you want to capture.Choose Next.In the Specify Session Data Storage page, select Save data to a file for later analysis and Work with only the most recent data.Choose Finish.You can now see your new session in the Sessions folder in SSMS. Choose (right-click) the session, and then choose Start session.-or-Run a query similar to the following to create an extended event session using T-SQL:CREATE EVENT SESSION [Deadlock_detection] ON SERVER ADD EVENT sqlserver.xml_deadlock_reportADD TARGET package0.event_file(SET filename=N'D:\rdsdbdata\Log\Deadlock',max_file_size=(100))WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=ON)GO     -- Start the event session  ALTER EVENT SESSION Deadlock_detection ON SERVER  STATE = start;  GODo the following to retrieve the deadlock information using SSMS:Open SSMS.On Object Explorer, Choose Management, and then choose Extended Events.Choose Sessions.Find the extended event session that you created earlier, and then choose (double-click) package0.event_file to open the extended event file.After the file contents have loaded, choose the event that you want to view, and then choose the Deadlock tab to view the graph.-or-Run a query similar to the following in T-SQL to view the list of deadlocks:SELECT * FROM sys.fn_xe_file_target_read_file('d:\rdsdbdata\log\deadlock*.xel', null, null, null)

Related informationMicrosoft documentation for Deadlock information tools