Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Before using SQL server 2008, in order to capture a deadlock, we had to create a server side/profiler trace or use trace flags 1204, 1222.
If you were lucky enough to work with SQL 2008/2008R2 you could have tried using XEvents (which were introduced in SQL 2008).
SQL Server 2012 added a new feature, System Health (SH). The System Health is the new default trace that we are familiar with, from the old days of SQL Server.
I have previously written about the SH ( System Health ).The most interesting addition regarding this post, is the automatic capture of deadlocks.
The deadlock can be seen in 2 ways:
1) On the XEvent monitor under the system_health monitor:
2) With a T-SQL query that connects to the System Health collector file:
SELECT xed.value('@timestamp', 'datetime') as Creation_Date,
xed.query('.') AS Extend_Event
FROM ( SELECT CAST([target_data] AS XML) AS Target_Data
FROM sys.dm_xe_session_targets AS xt
INNER JOIN sys.dm_xe_sessions AS xs
ON xs.address = xt.event_session_address
WHERE xs.name = N'system_health'
AND xt.target_name = N'ring_buffer')
AS XML_Data
CROSS APPLY Target_Data.nodes('RingBufferTarget/event[@name="xml_deadlock_report"]') AS XEventData(xed)
ORDER BY Creation_Date DESC
By clicking on the Extend_Event XML filed, we would get the XML file showing all the information about the transaction marked in yellow.
As I said before, System Health is a great tool for the XEvent. You’ll find there a lot of interesting information about your system.
Comments
- Anonymous
June 19, 2014
Thanks a bunch! I didn´t know about it. With this tip, you really help me with a production deadlock issue! - Anonymous
January 19, 2016
I have tried running the above query on SQL Server 2014 and it does not seem to work, any advice?