Database Reference
In-Depth Information
SQL Server maintains the predicate state within an event session. For example, the
package0.counter
attribute
stores the number of times the predicate was evaluated. You can rely on the predicate state if you want to create event
sessions that sample the data; for example collecting data for every 100th occurrence of the event or, perhaps, fire a
particular event only the first 10 times.
Actions
Actions
provide you with the ability to collect additional information with the events. Available actions include
session_id
,
client_app_name
,
query_plan_hash
, and many others. Actions are executed after predicates were
evaluated, and only if an event is going to be fired.
SQL Server executes actions synchronously in the same thread as the events, which adds overhead to event
collection. The amount of overhead depends on the action. Some of them, for example
session_id
or
cpu_id
, are
relatively lightweight. Others, such as
sql_text
or
callstack
, can add significant overhead to SQL Server when they
are collected with frequently fired events.
■
even though extended events are lightweight compared to sQL traces, they can still add considerable
overhead to the server when used incorrectly. do not add unnecessary load to sQL server, and collect only those events
and actions that are required for troubleshooting.
Important
You can examine the list of available actions by using the query shown in Listing 28-6. Figure
28-10
shows the
partial output of the query when run in SQL Server 2012.
Listing 28-6.
Examining actions
select
xp.name as [Package]
,xo.name as [Action]
,xo.Description
from
sys.dm_xe_packages xp join sys.dm_xe_objects xo on
xp.guid = xo.package_guid
where
(xp.capabilities is null or xp.capabilities & 1 = 0) and
(xo.capabilities is null or xo.capabilities & 1 = 0) and
xo.object_type = 'action'
order by
xp.name, xo.name
