Please make this be enabled per-server instead of globally. We have SQL 2008 servers which prevent our use of this feature due to well-documented issues (https://support.microsoft.com/en-us/help/2878139/fix-using-dbghelp-dll-version-4-0-5-error-is-logged-in-sql-server-2012)

I've added a suggestion: https://sqlmonitor.uservoice.com/forums/91743-suggestions/suggestions/31754800-enable-extended-events-per-server

I have noticed https://documentation.red-gate.com/display/SM7/Extended+Events

A question: does enabling this also turn off TF 1222 on monitored instances?

This TF is the most annoying since the default system health XE as well as event notification can capture the deadlock graphs. I am happy to share my event notification based solution instead of TF.

It doesn't really make sense using trace flags for deadlock detection since extended events has been around. Using the system health session is good because it is already built into the product. I would also like the option of having SQL Monitor create a separate deadlock XE, this is because I have worked with a few servers where the system_health XE gets flooded with other notifications so it gets cycled every few minutes.

Display the transactions involved in the dead lock in a graphical manner

select target_data as TargetData
from sys.dm_xe_session_targets st
join sys.dm_xe_sessions s on s.address = st.event_session_address
where name = 'system_health'

Gives nice XML data on my server, can't you use that?

Hi Morten,

Do you mean that you've not getting anything useful in the 'Details' tab of a Deadlock alert? If that's the case, please could you drop an email to support@red-gate.com (please mention me and this UserVoice thread) with the content from the 'Output' tab, making sure to retain the indentation, so we can take a look at this.

Many thanks,

Colin.

deadlock parsing is still broken for me with SQL Monitor 4.1.0.2226

Thanks for the suggestion, Can you explain further as to what you would hope to achieve by exporting to an external tool?
FYI, the output shown is exactly as presented to us by SQL Server, which somewhat unhelpfully strips out the XML tags. :o(

Export deadlock xml from output tab to view in external tool.

The view presented under the output tab is difficult to read and its an xml representation.

Alternatively just show the xml instead of the formatted text.

Add user and application to the details tab on a deadlock alert.
And to the email notification.

Thanks a lot for your feedback.

Hi Priya... It will still be much easier and more simple if we can get an "disable usage of trace flag 1204" button. Especially because we have to set specific permissions on ALL databases we want to monitor, if we want to avoid this trace flag. – This can of course be scripted etc. But the disable 1204 button, will just make it much more simple and easy.

For Deadlock alerts involving indexes/keys under the Details tab: the Lock details erroneously represent the hobt_id and index hash key as object id and index id respectively. Trying to SELECT OBJECT_NAME([object id]) will typically result in an overflow error, especially because the value being represented is the hobt_id. The hobt_id corresponds to the hobt_id column in sys.partitions from which the object_id can be derived.

In the attached example, 72057594042974208 is the hobt_id and (5d01b1d6d489) is the index hash key... NOT the object_id and index_id values.

Like you said Priya, if this could be done with little overhead, it could/would be very helpful.

Thanks Jonathan and Tim for the feedback. We will definitely review this and let you know our findings. Sometimes information can be extracted but it comes with a cost.

We try really hard to keep SQL Monitor light weight.. So that you should never notice any performance impact on the entities you are monitoring. Will update you when we have investigated this.

Thanks,
Priya

Oh, that is pretty cool. Thanks Tim! Your idea definitely gets my vote.

Having a call stack certainly helps increase visibility on the context where a particular issue is arising. And since SQL Deadlock Detector can do it, I don't see why SQL Monitor couldn't do it as well.

The screenshot is from another product, "SQL Deadlock Detector" from Lakeside Solutions. I meant to mention that in the original post for the new idea, in order to show that it's apparently possible to get that call stack information *somehow* since another product does it. :)

Where is screenshot from? I don't recognize it.

In the display of alert detail, rather than just showing the SQL fragment, show the full call stack. This helps to determine the context in which the fragment is running, since often the fragment alone is a piece of shared T-SQL code (like a UDF) that can be called by several vastly different pieces of code.