Diagnosing SQL Server 2012 Using Extended Events (part 3) - Extended Events Terminology - Events, Event Fields , Actions

4.2.2 Events

An event, like its name suggests, is something that happens within SQL Server that you’re interested in finding out more about. Events are defined by specific points in the SQL Server source code; and whenever a running task reaches one, a check is performed to determine whether the Extended Events engine currently has a session watching for that event to happen. If so, then the task is suspended while the Extended Events engine performs the session’s actions, something you’ll learn more about in a moment.

Checking for an event and then executing the session’s actions happen synchronously, meaning the user’s running task is halted until the actions are completed. Fortunately, the processes that perform these steps are very fast and efficient, which is why Extended Events is often described as being lightweight. Therefore, despite being synchronous, the overhead of this feature is very small; and regular usage even on production systems is not normally associated with lower performance.

Because the events we can monitor are written into the SQL Server source code, it’s not possible for us as end users to add our own, although Microsoft contends that it can ship custom events if needed. For example, Microsoft support engineers have said they can ship Extended Events modules to an end user for monitoring very specific errors. Despite that being a well-publicized option, these extra modules are certainly not downloadable; nor are we aware of anyone actually using them.

To store the event definitions and their internal code, the Extended Events engine uses its own storage containers, called packages. Several of these packages ship with SQL Server 2012, far more than were included with SQL Server 2008, and Microsoft can ship others as just mentioned. If you want to know what packages are available, you can query the names from one of the many DMVs that Extended Events provides. The following query is one example:

select name, description from sys.dm_xe_packages

On the RTM release of SQL Server 2012, the preceding returns the following results:

name         description
package0     Default package. Contains all standard types, maps, compare
             operators, actions and targets
sqlos        Extended events for SQL Operating System
XeDkPkg      Extended events for SQLDK binary
sqlserver    Extended events for Microsoft SQL Server
SecAudit     Security Audit Events
ucs          Extended events for Unified Communications Stack
sqlclr       Extended events for SQL CLR
filestream   Extended events for SQL Server FILESTREAM and FileTable
sqlserver    Extended events for Microsoft SQL Server

For those of you familiar with SQL Server’s other features, you’ll likely have spotted a package called SecAudit and associated it with the auditing feature within SQL Server. The auditing feature uses Extended Events itself as the mechanism to capture and log SQL Server event activity requested by security administrators. However, this package has extra security protection around it, so you can’t view or use any of its content yourself.

The events themselves, which you’re able to monitor for using Extended Events, are also visible through a DMV. They are stored with other Extended Events data so a where clause is needed:

select name, description from sys.dm_xe_objects where object_type = 'event'
order by name

If you’re familiar with Profiler or SQL Trace, then you are already familiar with some of the event names that the preceding query returns. If not, many of the event names are self-explanatory, such as sql_batch_completed, database_created and login. As you begin to browse through the long list, however, you’ll begin to see some of the newer monitoring capabilities that Extended Events offers, including events such as page_compression_attempt_failed, availability_replica_state_change, and wait_info.

For those of you who want to migrate away from using Profiler, it’s possible to look up the name of the Profiler events you’re familiar with and find their equivalent in Extended Events through the mapping query shown here:

select t.trace_event_id as 'Trace Event ID', t.name as 'Trace Event Name',
       x.xe_event_name as 'XE Event Name'
from   sys.trace_events t
join   sys.trace_xe_event_map x
on     t.trace_event_id= x.trace_event_id

4.2.3 Event Fields

Once you understand what an event is, the concept of an event field is easily understood. Whereas an event is something that occurs, an event field is a piece of data about that event. For example, some of the event fields for the sql_statement_starting event are line_number, offset, offset_end, and statement, all pieces of data that could be useful in diagnosing an expensive statement. You can query the list of event fields for an event from the Extended Event DMVs, as shown in the following example query for the event fields just mentioned:

select  c.name, c.description
from    sys.dm_xe_object_columns c
join    sys.dm_xe_objects o on o.name= c.object_name
where   o.name = 'sql_statement_starting'

You probably noticed from the query results that the number of event fields for an event is relatively small, far smaller than you might expect in order to do any comprehensive troubleshooting. If the event for which you want to capture data doesn’t provide the information you need in the fields associated with it, don’t panic. One of the benefits of Extended Events is that when an event occurs, you can have the session capture additional data for you. This is done using actions.

4.2.4 Actions

As mentioned in the preceding section, when an event you’ve configured a session to monitor for occurs, it’s unlikely that the event itself will provide all the data required to perform your troubleshooting. The example just shown was sql_statement_starting, containing only the fields line_number, offset, offset_end, and statement, which by themselves probably aren’t adequate to diagnose an issue. You would likely want some additional information, such as the session ID, the user name, or perhaps the query plan’s handle.

Actions are the way that Extended Events provides you with the extra data you want about an event. You can think of the term action as meaning “go and get some additional data,” as despite their name they rarely perform a task other than a data lookup. In fact, in SQL Server Management Studio, the Actions window is also called Global Fields, which is arguably a more accurate name for them. A few actions, however, do perform tasks other than a data lookup, such as creating a mini-dump or even halting SQL Server. These are technical tasks aimed at hardcore debugging; you won’t find an action with a name like “Execute stored procedure” in Extended Events.

There are 48 actions, or global fields, that ship with SQL Server 2012; and like the events themselves, they are defined in the SQL Server source code so it’s not possible to add your own. You can query which are available through a provided DMV:

SELECT name, description  FROM sys.dm_xe_objects WHERE object_type = 
'action' and capabilities_desc is null ORDER BY name

The results returned by the query provide the names and descriptions of the extra fields that a session can be configured to collect. As you’ll see later, though, they are all listed in the SSMS interface along with all the other session options, so there’s no need to remember the contents of any DMVs.

How this captured data is handled once it is collected is one of the main differences between Extended Events and other troubleshooting technologies — and a main benefit. Once an action has captured the extra data it needs, writing it to a logging destination — for example, a flat file — can be done asynchronously. When this is configured, the event’s data is written to internal buffers; and the SQL Server task that caused the event can then continue. The overhead of actually writing the data to disk is offloaded to an asynchronous task, so it doesn’t affect the performance of the user’s query. This is one of the many reasons why this feature can be used on busy production systems.