Databases Reference
In-Depth Information
Extended Events Terminology
Hopefully, by now you're beginning to understand the powerful foundations upon which Extended
Events is built upon, and why and how you might use it. If not, don't worry, as you'll be looking
at some examples demonstrating when and how to use this feature in the next section. Before that,
however, this section reviews the terminology that Extended Events uses. Like all SQL Server fea-
tures, Extended Events has its own names for objects and methods, and this section should serve as
a comprehensive glossary for them.
Sessions
An Extended Events session is a user-dei ned combination of
events, actions, i lters, and targets, which is stored within the
SQL Server instance, although SQL Server also ships with
some of its own system sessions as well. Each session can be
coni gured to start either manually on request or automati-
cally when SQL Server itself starts. Once a session is started,
it tells the Extended Events engine to begin monitoring for the
specii ed events, and what to do should they happen. You can
think of the Extended Events engine as a controller and coor-
dinator within the SQL Server engine for everything related to
Extended Events.
You can create a session using either T-SQL commands or,
new in SQL Server 2012, the GUI available through SQL
Server Management Studio. Using the GUI, you can create,
manage, and view sessions and their captured data entirely
through SQL Server Management Studio. It is this new GUI
tool that we focus on using in this chapter. Figure 13-2 shows
you where in SQL Server Management Studio you can i nd it
and any sessions that may have been coni gured.
FIGURE 13-2
In this case, i ve sessions are currently coni gured, four of which
are running. You can stop and start them, as well as i nd addi-
tional options, by right-clicking on a session, as shown in
Figure 13-3.
Of the i ve sessions shown, note that Logins, PageSplit, and
LockDemo are user-dei ned sessions; the other two are system-
dei ned sessions that SQL Server uses internally to provide both
itself and administrators with system information. The session
AlwaysOn_health looks for expected and unexpected changes
to AlwaysOn Availability Groups so they can be displayed in the
AlwaysOn dashboard. The system_health session is very similar to
the default trace SQL Server also has, a “black box” critical event
recorder that can be used to retrospectively diagnose critical sys-
tem issues.
FIGURE 13-3
Search WWH ::
Custom Search