4. WHAT ARE EXTENDED EVENTS?
To clarify what Extended Events are,
they are a feature within the SQL Server database engine that enables
SQL Server to watch for and then respond to specific database engine
events occurring. These events could be as simple as a user logging in
or something more technical such as a long-running I/O operation. When
a watched for event occurs, the Extended Event session performs an action,
which is typically to gather additional information about what has just
happened. For example, when a long I/O operation occurs, you might want
to record the SQL Server statement to which the event was related. All
the information collected is sent to a target
where it’s stored. This could be something as simple as a flat file,
but Extended Events also provides a few advanced storage options that
can process the collected data rather than just store it. Figure 1 provides an illustration of this basic process.
4.1 Where the Name Extended Events Comes From
Although the name Extended Events
provides a clue as to what it’s about, it is not as prescriptive as
something like Resource Governor. The Extended Events feature within
SQL Server takes its name partly from a high-performance
troubleshooting feature in the Windows operating system called Event
Tracing for Windows (ETW), a low-level debugging tool that exposes
kernel-level events generated by applications or device drivers. It is
normally used by developers during development and troubleshooting.
Some SQL Server tuning experts use it to obtain very detailed
performance data from Windows. ETW has been around since Windows Server
2000, and it introduced the Windows kernel concepts of controllers,
providers, and consumers of event data, terminology that’s still used
today.
Rather than get very technical, it is sufficient
to know that the Extended Events feature was built on the fundamental
design principles of ETW, in terms of both its architectural design and
its object-naming conventions. The events it refers to are simply
“things that happen” within your system, such as a query being
executed, a physical file being read, or a memory request being granted
— similar to what you are used to seeing in Profiler, but there are
more of them, covering more areas. Fortunately for us, SQL Server hides
all this low-level complexity and just exposes objects and commands
that we can relate to as database professionals.
4.2 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
features, Extended Events has its own names for objects and methods,
and this section should serve as a comprehensive glossary for them.
4.2.1 Sessions
An Extended Events session is a
user-defined combination of events, actions, filters, 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 configured to start either manually on request or automatically
when SQL Server itself starts. Once a session is started, it tells the
Extended Events engine to begin monitoring for the specified events,
and what to do should they happen. You can think of the Extended Events
engine as a controller and coordinator 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. Figure 2 shows you where in SQL Server Management Studio you can find it and any sessions that may have been configured.
In this case, five sessions are currently
configured, four of which are running. You can stop and start them, as
well as find additional options, by right-clicking on a session, as
shown in Figure 3.
Of the five sessions shown, note that Logins,
PageSplit, and LockDemo are user-defined sessions; the other two are
system-defined 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 system issues.
Sadly, the SQL Server Management Studio
interface for Extended Events appears only when you connect to an
instance of SQL Server 2012. Although Extended Events existed in SQL
Server 2008, you need to use one of the graphical tools created by SQL
Server community members in order to connect to SQL Server 2008
instances and manage the Extended Events sessions, or use the T-SQL
commands.