Extended Events packages

Applies to: SQL Server Azure SQL Database Azure SQL Managed Instance

A package is a container for Extended Events objects in the SQL Server Database Engine. For example, the following there packages exist in any Database Engine that supports Extended Events:

  • package0 - Extended Events system objects. This is the default package.
  • sqlserver - Objects related to the Database Engine
  • sqlos - SQL Operating System (SQLOS) related objects.


The SecAudit package is used internally by the Audit feature. None of the objects in this package are available through the Extended Events data definition language (DDL).

Packages are identified by a name, a GUID, and the binary module that contains the package. A module can be an executable or a dynamic link library. For more information, see sys.dm_xe_packages.

A package can contain any or all of the following objects, which are discussed in greater detail later in this article:

  • Events
  • Targets
  • Actions
  • Types
  • Predicates
  • Maps

Objects from different packages can be mixed in an event session. For more information, see Extended Events sessions.

Package contents

The following illustration shows the objects that can exist in a package.

Diagram that shows the relationship of a module, packages, and objects.


Events are monitoring points of interest in the execution path of a program, such as SQL Server. When an event fires, it contains the fact that the point of interest was reached, and 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.


An event doesn't have any knowledge of the actions that can be triggered in response to the event firing.

A set of events in a package can't change after the package is registered with Extended Events.

All events have a versioned schema that defines their contents. This schema is composed of event columns with defined types. An event of a specific type must always provide its data in exactly the same order that is specified in the schema. However, an event target doesn't have to consume all the data that is provided.

Event categorization

Extended Events uses an event categorization model similar to Event Tracing for Windows (ETW). Two event properties are used for categorization, channel and keyword. Using these properties supports the integration of Extended Events with ETW and its tools.

A channel identifies the audience for an event. Channels are described in the following table.

Term Definition
Admin Admin events are primarily targeted to end users, administrators, and support. The events that are found in the Admin channel can indicate a problem with a well-defined solution that an administrator can act on. An example of an admin event is when an application fails to connect. These events are either documented or have a message associated with them that tells the reader what to do to rectify the problem.
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.
Analytic Analytic events are published in high volume. They describe program operation and are typically used in performance investigations.
Debug Debug events are used primarily by developers to diagnose a problem for debugging.

Events in the Debug channel return internal implementation-specific state data. The schemas and data that the events return can change, become invalid, or be removed in future versions of the Database Engine without notice.

A keyword is application-specific and enables a finer-grained grouping of related events, which makes it easier for you to specify and retrieve an event that you want to use in a session. You can use the following query to obtain keyword information.

SELECT map_value AS Keyword
FROM sys.dm_xe_map_values
WHERE name = 'keyword_map';


Targets are event consumers. Targets process events, either synchronously on the thread that fires the event or asynchronously on a system provided thread. Extended Events provides several target types that you can use as appropriate for directing event output. For more information, see Targets for Extended Events.

You use the ADD TARGET clause to add targets to an event session.


An action is a programmatic response or series of responses to an event. Actions are bound to an event, and each event can have its own set of actions.


Actions that are intended for specific events can't bind to other events.

An action bound to an event is invoked synchronously on the thread that fired the event. There are many types of actions and they have a wide range of capabilities. Actions can:

  • Capture a process dump
  • Store state information in a local context using variable storage
  • Aggregate event data
  • Append data to event data

Common examples of using actions include:

  • Collect SQL text of a query being executed by the thread firing the event
  • Collect query plan handle, query hash, and query plan hash
  • Collect attributes of a session that causes the event to be fired, including client host name, principal name, connection ID, etc.
  • Collect the call stack
  • Capture a process dump when a specific error occurs

You use the ACTION clause to add actions to an event session.


Predicates are a set of logical rules that are used to evaluate events when they are processed. This enables the Extended Events user to selectively capture event data based on specific criteria.

Predicates can store data in a local context, which can be used to create predicates that return true once every n minutes or every n times that an event fires. This local context storage can also be used to dynamically update the predicate, thereby suppressing future event firing if the events contain similar data.

Predicates have the ability to retrieve context information, such as the thread ID, as well as event specific data. Predicates are evaluated as full Boolean expressions, and support short circuiting at the first point where the entire expression is found to be false.


Predicates with side effects might not be evaluated if an earlier predicate check fails.

You use the WHERE clause to add predicates to an event session.


In a package, each Extended Events object has a type. The following types are used:

  • action
  • event
  • message
  • pred_compare
  • pred_source
  • target
  • type

For more information, see sys.dm_xe_objects.


A map table maps an internal value to a string, which enables a user to know what the value represents. Instead of only being able to obtain a numeric value, a user can get a meaningful description of the internal value. The following query shows how to obtain map values.

SELECT map_key, map_value
FROM sys.dm_xe_map_values
WHERE name = 'lock_mode';

The preceding query produces the following output:

map_key map_value
0 NL
3 S
4 U
5 X
6 IS
7 IU
8 IX
10 SIX
11 UIX
12 BU
13 RS_S
14 RS_U
15 RI_NL
16 RI_S
17 RI_U
18 RI_X
19 RX_S
20 RX_U

Using this table as an example, assume that you have a column named lock_mode, and its value is 5. The table indicates that 5 maps to X, which means the lock type is Exclusive.