3. SQL Server Extended Events
SQL Server Extended Events (SSEE) are truly the
future event-oriented framework that all SQL Server–based systems and
applications will be using going forward. Extended Events are highly
flexible to define, are able to capture almost any action or event
within your reach, are lightweight in their implementation, and are
flexible enough to create simple or complex monitoring across multiple
systems and environments. In other words, SSEE is a unified approach to
handling events across SQL Server systems, while at the same time
enabling users to isolate specific events for troubleshooting purposes.
The Extended Events framework can be utilized to help
SQL Server implementations in many ways. Some approaches might include
the following:
Isolating excessive CPU utilization
Looking for deadlocks/locking
Locating long-running SQL queries
One of the key features of Extended Events is that
events are not bound to a general set of output columns like SQL Trace
events. Instead, each Extended Event publishes its data using its own
unique schema. This makes the system as flexible as possible for what
can be returned from Extended Events. The Extended Event system was
engineered from the ground up with performance in mind, so events should
have minimal impact on system performance.
SSEE currently is T-SQL based (there is no GUI tool
available for SSEE yet). However, it has several predefined SQL Server
catalog and dynamic management views and also is integrated with the
Event Tracing for Windows (ETW) tools. Figure 17 shows the overall makeup of the new SSEE framework.
There
is basically an Extended Event engine that runs within SQL Server and
drives the event gathering for active sessions. This capability
essentially provides a standard and powerful way to dynamically monitor
active processes, while at the same time having minimal effect on those
processes.
Looking a little closer at Figure 39.18,
you can see the concept of Extended Events packages (a package), which
contain one or more Extended Events objects. The Extended Events engine
allows any event to be bound to any target. In other words, events can
push their results to any location for consumption (like the ETW) or can
be exposed via Views in SMSS, and so on.
Predicates are used to filter what events (that are
firing) get pushed to the target (consumer). This capability greatly
adds to the flexibility of the Extended Events infrastructure.
The next sections examine the main elements of Extended Events.
Packages
A package is a
container for SQL Server Extended Events objects. It is the basic unit
within which all other Extended Event objects ship. Four kinds of
Extended Events packages are included in SQL Server 2008:
package0— Extended Events system objects. This is the default package.
sqlserver— SQL Server–related objects.
sqlos— SQL Server Operating System (SQLOS)–related objects.
SecAudit— Security Audit events.
You can see these four packages by running the following query:
select * from sys.dm_xe_packages
Packages can interact with one another to avoid
having to provide the same code in multiple contexts. In other words, if
one package exposes an action that can be bound to an event, any number
of other events in other packages can also use it. For example, the package0 package that ships with SQL Server 2008 contains objects designed to be used by all the other packages.
A package can contain any or all of the following objects:
Events
Events
are monitoring points of interest in the execution path of a program,
such as SQL Server. An event firing indicates that the point of interest
was reached and provides state information from the time the event was
fired. Events can be used solely for tracing purposes or for triggering
actions. These actions can either be synchronous or asynchronous. There
can be one or more events in an event session package.
To see a list of the events provided with SQL Server, you can run the following query:
select * from sys.dm_xe_objects where object_type = 'event'
As stated previously, events have a schema that
defines their contents. This schema is composed of event columns with
well-defined types. You can view the event schema by querying sys.dm_xe_object_columns, as in the following example:
select name, column_id, type_name, column_type
from sys.dm_xe_object_columns
where object_name = 'page_split'
go
name column_id type_name column_type
------- ----------- ------------ -----------
ID 0 uint16 readonly
UUID 1 guid_ptr readonly
VERSION 2 uint8 readonly
CHANNEL 3 etw_channel readonly
KEYWORD 4 keyword_map readonly
file_id 0 uint16 data
page_id 1 uint32 data
Columns marked with column_type data are the
values that will be filled in at runtime. The read-only columns provide
metadata about the event. Notice that one of the columns in the output
is the channel for the event; this indicates the category of the event.
The available event channels in SQL Server 2008 are as follows:
Admin—
Admin events are primarily targeted to the end users, administrators,
and support. They include events such as error reports and deprecation
announcements.
Operational—
Operational events are used for analyzing and diagnosing a problem or
occurrence. They can be used to trigger tools or tasks based on the
problem or occurrence. An example of an operational event is one in
which a database is attached or detached.
Analytic—
Analytic events are those that fire on a regular basis, often in high
volume. They describe program operation such as lock acquisition and SQL
Server statement execution. They are typically aggregated to support
performance analysis.
Debug— Debug events are used solely by DBAs and support engineers to help diagnose and solve engine-related problems.
