1. INTRODUCTION TO EXTENDED EVENTS
If you’re familiar with recent versions
of SQL Server, then it’s likely you’ll have heard of Extended Events,
also known as XE or XEvents, and you know that it’s a diagnostics
feature built into the database engine. For most people, however, their
knowledge of it is not much more than that. The lack of a need to use
it and a challenging command set in the first release in SQL Server
2008 meant that learning to use it was often a low priority on people’s
“to do” list.
Fortunately, SQL Server 2012 should change that,
as not only has the product’s documentation made it clear that Extended
Events is set to become one of SQL Server’s primary diagnostic tools in
future versions, but also, and perhaps more important, a graphical user
interface for it is now part of SQL Server Management Studio. No longer
does a complex set of T-SQL commands need to be understood before you
can use the feature.
After reviewing how Extended Events work and
the terminology it uses, you’ll see how easy it is to start capturing
diagnostic information, and how to start doing things that previous
generations of tools like Profiler and SQLTrace both did and didn’t let
you do. Finally, you’ll look at how to analyze the data that Extended
Events captures.
2. GETTING FAMILIAR WITH EXTENDED EVENTS
Extended Events is a database engine feature that
captures troubleshooting information about events you’re interested in
finding out more about. However, unlike previous generations of tools,
it has very little overhead on the system it’s monitoring, not
capturing diagnostic data until an event is triggered by a very
specific set of configured database engine events. This differs from
tools, such as Profiler or SQLTrace for which, even with clever
filters, you typically need to capture large volumes of event-related
data, and then manually match your troublesome event’s occurrence to
other sources of data you capture around that time.
In fact, it’s almost certain that if you’ve
previously done any diagnostics work in SQL Server you’ll have used the
SQLTrace or Profiler tools, and it’s these technologies specifically
that Microsoft is aiming to replace with Extended Events (eventually).
Unlike SQLTrace or Profiler, the “sit and wait”
approach of Extended Events enables you to capture only the data that’s
of interest to you, reducing both the volume of data that needs
reviewing and the load you place on SQL Server. Of course, you can
still use Extended Events to capture large amounts of data for a very
broad range of events if that’s what you want — in fact, its
flexibility is another of its benefits.
Another benefit just briefly mentioned is that
unlike previous generations of debugging tools, using Extended Events
adds very little overhead to the system being monitored, both because
of how it does the actual monitoring and how it then records the data
it subsequently captures. Indeed, from its very inception, Extended
Events was designed to be lightweight and therefore something you can
use on servers with even the heaviest of workloads; that’s not
something you could say about previous tools like Profiler.
In addition to the more traditional use
of Extended Events by DBAs and developers for troubleshooting
performance, security, and functionality issues, Windows system
administrators can also hook into Extended Events as a source of
debugging data about what SQL Server is doing. In fact, Extended Events
are very closely related to a hardcore debugging system called Event
Tracing for Windows, which will be familiar to people who debug Windows
at the kernel level.
3. WHY YOU SHOULD BE USING EXTENDED EVENTS
While Extended Events have been around
since the release of SQL Server 2008, they have not been as popular as
one might expect for such a powerful troubleshooting feature. You might
still be wondering then if now is a good time to begin using them. This
section addresses that question by reviewing three of the primary
reasons why people are now using Extended Events, along with some
examples demonstrating when you might choose to use them.
SQL Server Roadmap
The first reason to consider using
Extended Events now is driven by Microsoft’s diagnostic tools road map
for SQL Server. According to Microsoft, the tools most people currently
use for troubleshooting, SQL Trace and Profiler, are slated for
retirement in a future version of SQL Server. Their replacement, as you
can probably guess, is Extended Events; and even SQL Server 2012
includes new functionality for Extended Events, whereas SQL Trace is
starting to be left behind. Fortunately, it’s very likely that whatever
you do today with Profiler you can also do with Extended Events.
If after using SQL Server for many years you’ve
built up a library of Profiler based monitoring sessions, all is not
lost, as there are several migration options and aids available for
you. Microsoft provides some migration mappings in some SQL Server DMVs
for people who want to migrate between the Profiler and Extended
Events, while boB “The Tool Man” Taylor has recently released an actual
conversion tool called SQL PIE (Profiler Into Events) that will be
downloadable soon from Codeplex.
Graphical Tools
The second reason to use Extended
Events now is that SQL Server 2012 delivers out-of-the-box what
Extended Events in SQL Server 2008 lacked, a graphical user interface
(GUI). Unlike other new SQL Server features that were embedded in SQL
Server Management Studio, the adoption of Extended Events was hindered
by this lack of a GUI. Instead, learning a new T-SQL command set stood
in the way of using them, along with the need to know how to query XML
data. Although a GUI tool was written by a community member for SQL
Server 2008, you had to be interested enough in Extended Events to find
and then use it. Even now, you can probably begin to see why Microsoft
had to deliver improvements in SQL Server 2012 if they were ever going
to realistically be able to retire the SQL Trace components.
Fortunately, Microsoft did respond, and SQL
Server 2012 includes a native graphical interface for Extended Events
built into SQL Server Management Studio. Now it’s possible to create,
deploy, and monitor reasonably complex Extended Events sessions without
having to use any T-SQL commands or query XML data. Of course, there
are always benefits if you choose to do that, but they’re no longer
compulsory as they were in SQL Server 2008.
Low Impact
Finally, if the preceding two reasons
aren’t enough to persuade you to begin using Extended Events, then
consider the nearly zero overhead that using them has on SQL Server.
Extended Events is often called “lightweight” for good reasons. First,
it is embedded deep within the SQL Server engine, which means it
requires far less code to function compared to older tools that connect
to SQL Server like a regular user does before they send event data.
Second, although other tools such as Profiler may try to limit the
amount of data they request, they tend to use inherently inefficient
mechanisms within SQL Server that often results in capturing more data
than is needed.
Instead, Extended Events take a reactive
approach, only collecting and sending data to their target when a
previously configured situation being monitored for occurs. If that
event doesn’t happen, then the SQL Server engine will not capture or
store any event data. Microsoft has measured just how lightweight the
events architecture that Extended Events use actually is, and
determined that 20,000 events per second firing on a server with a 2
GHz Pentium CPU and 1GB of memory consumed less than 2% of the CPU’s
resource — and that’s on a very old specification server!
Of course, it’s always possible to configure
anything badly and suffer undesirable consequences, including with
Extended Events, so low overhead should not be an excuse to avoid
planning and testing their deployment into your production
environments. In fact, it’s even possible to purposely configure an
Extended Events session to stop SQL Server when a specific event
occurs; it’s that powerful! However, to do that, you would have to
deliberately configure that very specific action to occur, so don’t
worry that you could accidentally stop SQL Server.
When You Might Use Extended Events
Having discussed some of the reasons
why you might want to use Extended Events, this section considers what
you might use it for. If you’re already familiar with tools like
Profiler and SQL Trace, then you will already be familiar with these
examples based on your current monitoring:
- Troubleshooting blocking and deadlocking
- Finding long-running queries
- Tracking DDL operations
- Logging missing column statistics
After you start to explore some of the more
advanced capabilities of Extended Events, you’ll see it’s just as easy
to track events such as the following:
- Long-running physical I/O operations
- Statements that cause specific wait stats to occur
- SQL Server memory pressure
- AlwaysOn Availability Groups events
