Ring Buffer
Having looked at some of the
options for sessions, we return now to some of the other targets that
SQL Server allows a session to use. The ring buffer behaves much like
the event file target in that it’s an asynchronous target for events to
be written to, and it stores them in a FIFO list. A big difference,
however, is that SQL Server Management Studio doesn’t provide a way to
translate its XML contents into human-readable data like it does for
the event file. Instead, a T-SQL query needs to be used to extract the
fields you want out of the ring buffer; and while this is relatively
straightforward, it’s a step
back from the simplicity that the graphical user interface provides to
newcomers of the feature.
Another difference of the ring buffer is that it
doesn’t use any physical storage — it’s purely an in-memory structure,
much like the memory buffer itself. Obviously, this means that data in
it is lost not only when the ring buffer fills up and space has to be
made for new events, but also whenever SQL Server itself is stopped.
This doesn’t make it suitable for reactive monitoring of historic
system issues; but because you can have a target with a very low write
latency that doesn’t need housekeeping afterward, it is suitable for
either high-level real-time monitoring of production systems or
low-level controlled testing on development systems.
The ring buffer has two size parameters
you can configure: either the total amount of memory it will use, or
the amount of memory per event it will use. Until you understand more
about how you can use the ring buffer, the default settings are more
than adequate.
Event Counter
The event counter is one of three
targets that don’t store any of the event data sent to them but instead
perform a task with it. The event counter target does what its name
suggests; it counts the number of times the event occurs. Unlike some
other targets, however, it doesn’t require any event data or actions to
be sent to it; the fact that the event has occurred is all it requires
to increment the counter value it’s maintaining. In order to provide an
accurate event count, access to update it is serialized, so it has to
be used as a synchronous target. This shouldn’t cause you any
performance issues though, as it’s a very lightweight target that
requires very little data to be sent to it.
Event counters, like the ring buffer, are
in-memory structures. Therefore, their content is never written to an
event file and is lost when SQL Server shuts down.
Histogram
The histogram could well be the most
useful target in your early, and perhaps later, stages of
troubleshooting — if only to begin identifying trends in your data that
enable you to focus on a particular type of event’s details.
For example, the wait_stat
event reports every type of wait stat as they occur, but you’ll
probably want to know which types of wait stats occur the most often.
If you were to use the event counter target, that would just tell you
the total number of wait stats that have occurred so far, whereas the
histogram will tell you how often each type of wait stat has occurred.
At this point, however, you begin to see where
the user-friendly and quick-to-deploy side of Extended Events is
countered by the programmatic T-SQL and XML-heavy side of the feature.
When the histogram reports aggregated data about event activity, it
uses internal identifiers rather than the friendly names we’re used to
in its results, as shown in Figure 4.
This indicates that wait stats 796 and 131 are occurring the most often, but a DMV lookup is needed to know what they are:
select map_key, map_value from sys.dm_xe_map_values where name =
'wait_types' order by map_key
In this instance, you can manually look up the wait types and see they were DIRTY_PAGE_POLL and LOGMGR_QUEUE.
Ultimately, you would want to query the histogram using T-SQL so you
can map the values to the corresponding collected results.
Histograms are clearly useful when you’re
capturing data about “busy” events and need to know more about the data
they’re returning, but if you want to use SSMS exclusively you’ll have
to become familiar with some of the internal names Extended Events
uses. Again, like event counters, histograms are in-memory structures,
so their content is never written to an event file. Therefore, it is
lost when SQL Server shuts down.
Pair Matching
The pair matching target is
another event data-handling, rather than storage, target that enables
you to discard two sets of related event data from your results. The
example that’s always used to demonstrate how this works is the data
captured for the lock acquired and lock released events. If a lock is
acquired but then subsequently released you’re probably not interested
in storing information about that having happened, and the pair
matching target will discard both of those events. What you’re more
likely to be interested in are locks being acquired but not released by
the same statement. If so, then using this target is appropriate.
Event Tracing for Windows (ETW)
This is the last target that
Extended Events in SQL Server 2012 has and it is at the very hardcore
end of the feature’s capabilities. Using the ETW target enables SQL
Server to integrate its event data with external Windows debugging
software so that a complete picture of a system’s performance can be
captured. It’s not something a SQL Server professional would typically
do, but for those of you interested in the technology there are some
excellent articles about it on the MSDN website.
