In a previous post, we discussed ways that DBAs could more proactively monitor environments and stay ahead of the game—in that case, using SQL Server event notifications to prevent deadlocks. In this post, we will feature another method for preventing deadlocks: extended events. Extended events are a lightweight event-handling platform introduced in SQL Server 2008. This platform captures events, such as wait events, user errors, and deadlocks, as they occur. After the events have been triggered, additional information that may be useful in troubleshooting the event can be appended to it before it is sent to a destination, or target, that can be easily queried. Extended events are very similar to what is available through SQL Profiler or SQL Trace. In fact, it is intended as a replacement for both technologies. With the next release of SQL Server, code-named “Denali,” SQL Profiler will be deprecated for the SQL Server engine. Extended Events: High-Performance Troubleshooting Capability A key benefit to extended events is its performance when compared to other monitoring options. With SQL Trace, there is often the concern that SQL Trace sessions can add to a performance issue. Extended events were designed with performance in mind, and tests have shown that the impact of extended events on transactions is about two microseconds per triggered event. Additionally, while events are triggered synchronously, many destinations for extended events are populated asynchronously, further reducing the likelihood that the monitoring will have an impact on performance. In order to be as flexible as possible, extended events were designed so that a triggering event can be sent to any of the available destinations. This means that any destination, or target, can receive any single event or multiple events without needing special configuration to handle the various events. Also, any group of events can be bundled together in extended event sessions. If the properties of an event change over time, the session information is as valid with the first version of the event collected as it is with the future versions. Extended events provide a depth of information about events that far exceeds what is available through SQL Trace, SQL Profiler, Performance Monitor, or many of the DMVs within SQL Server. These other tools can provide high-level information on page splits, latches, and wait stats. Only extended events can look at when these events occur and provide information such as the plan handle, T-SQL stack, and much more, as they are triggered within the database. Extended events provide a high-performance doorway to look into SQL Server to monitor and provide valuable troubleshooting information. Most of this information is available in other tools and features, but not in a manner that performs as well as extended events. Resolving Deadlocks with Extended Events Extended events allow another way to monitor deadlocks. In SQL Server 2008, an extended event session named system_health is automatically created and started. One of the events that this session captures is the deadlock graph. Without any setup or configuration, deadlocks in the system_health session can be accessed through the use of the query below. Running this query returns the deadlock graph and the time in which the deadlock occurred. These can be used to start digging into the causes of the deadlock. In situations where you haven’t set up deadlock monitoring, information necessary to troubleshoot recent deadlocks is already being stored. If your SQL Server environment contains SQL Server with versions lower than SQL Server 2008 Service Pack 1 Cumulative Update Package 6 or SQL Server 2008 R2 Cumulative Update Package 1, you will encounter a bug converting the deadlock graphs above into XML. The issue is detailed in the Knowledge Base article 978629. To resolve the issue, use the query below instead: More information about extended events can be found in our whitepaper “ How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues”.
↧