Creating an Extended Events Session
Microsoft uses the same common paradigm (CREATE, ALTER, DROP) for most of its newer capabilities, such as Create Audit.. (for SQL Auditing), Create Endpoint..
(for database mirroring), and many others. SSEE follows the same path
in that you basically create an Extended Events session, alter it to
start the monitoring session, alter it again to stop the monitoring, and
then leverage the catalog and dynamic management views before, during,
and after the session monitoring to view the event information.
Creating events (event sessions) is fairly easy to do using the CREATE, ALTER and DROP EVENT
statements. These Data Definition Language (DDL) statements completely
control the creation and activation of Extended Events. All the SSEE
objects are created in the msdb database. Only those users with CONTROL SERVER permissions can create, alter, or drop SSEE objects. To use the catalog and dynamic management views, you need at least VIEW SERVER STATE permission.
In this section, you quickly set up and define a new
Extended Events session object that includes operating system IO
requests and SQL Server lock-acquired counts. The purpose is to isolate
the database objects (tables) that are being hit hardest with locks to
better understand the behavior of the database design.
Locate this SQL script now; then start SSMS and open a new query connection with the CREATE EVENT SESSION script in it. Figure 18 shows a current connection to SQL Server with TheMostLocks.sql file open and the event session named TheMostLocks ready to be created.
As you examine the CREATE EVENT SESSION T-SQL code, notice that two events are being created with the ADD EVENT
statements. One will gather async IO requests, and the other will
retrieve SQL Server–acquired locks on an object’s information. Also,
notice the TARGET statement, which uses a predefined target
location that allows you to retrieve the results within SQL Server
during execution and that filters on showing only the lock’s acquired
information.
The CREATE EVENT SESSION T-SQL code is as follows:
IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='TheMostLocks')
DROP EVENT session TheMostLocks ON SERVER;
CREATE EVENT SESSION TheMostLocks
ON SERVER
ADD EVENT sqlos.async_io_requested,
ADD EVENT sqlserver.lock_acquired
ADD TARGET package0.synchronous_bucketizer (
SET filtering_event_name='sqlserver.lock_acquired',
source_type=0, source='resource_0')
WITH (MAX_MEMORY=4MB, MAX_EVENT_SIZE=4MB);
Alternatively, you can direct the TARGET output to a file by using the following TARGET statement, for example:
ADD TARGET package0.etw_classic_sync_target
(SET default_etw_session_logfile_path = N'C:\TEMP\EESessionFile.etl' )
You could then use the resulting file with the ETW to assemble this and other events from other portions of your environment.
After the event session is created, you are able to start it by using the ALTER EVENT SESSION
command, generate some activity on your server that will be captured by
the event session, view the dynamic results during the execution of the
activity, and then stop the event session.
Go ahead and create the event session as it is listed now. Simply highlight the CREATE EVENT SESSION
T-SQL statements shown previously and execute this code from SSMS. When
it is complete, you are ready to start the event session by using the
following command:
-- START EVENT SESSION
ALTER EVENT SESSION TheMostLocks ON SERVER STATE=start;
Using the AdventureWorks2008 database, you
can generate some simple activity that is known to acquire share locks
on tables. Use the following T-SQL that references the [Sales].[vSalesPersonSalesByFiscalYears] view:
--
-- Generate some lock acquiring workload
--
USE AdventureWorks2008;
SELECT TOP 1 * FROM [Sales].[vSalesPersonSalesByFiscalYears];
As soon as the preceding SELECT statement is generated, the Extended Event begins doing its job of collecting information. As you can see in Figure 19,
this fairly complex join statement grabs the results of this Extended
Event and displays them in a very nice readable fashion.
As you can see, this session isolates the table
objects that have the most acquired locks on them during execution. This
capability is very powerful.
The T-SQL code is as follows:
-------------------------------------------------------------------
-- The following query turns the xml data that is accumulating --
-- from the Extended Event Session and displays it more clearly --
-- TableName, TableObjectID, and number of AcquiredLocks --
-------------------------------------------------------------------
SELECT name AS TableName,
object_id AS TableObjectID,
LocksX AS AcquiredLocks
FROM (SELECT objstats.value('.','bigint') AS ObjectX,
objstats.value('@count', 'bigint') AS LocksX
FROM (SELECT CAST(xest.target_data AS XML)
LockData
FROM sys.dm_xe_session_targets xest
JOIN sys.dm_xe_sessions xes ON xes.address = xest.event_session_address
JOIN sys.server_event_sessions ses ON xes.name = ses.name
WHERE xest.target_name = 'synchronous_bucketizer'
AND xes.name = 'TheMostLocks'
) Locks
CROSS APPLY LockData.nodes('//BucketizerTarget/Slot') AS T(objstats)
) LockedObjects
INNER JOIN sys.objects o
ON LockedObjects.ObjectX = o.object_id
WHERE o.type != 'S'
AND o.type = 'U'
ORDER BY LocksX desc;
To turn off the Extended Events session, you simply issue another ALTER EVENT SESSION command with the STATE equal to stop, as shown here:
-- STOP EVENT SESSION
ALTER EVENT SESSION TheMostLocks
ON SERVER STATE=stop ;
Various Extended Events can be defined for
monitoring purposes within the SQL Server environment, your application
environment, and at the operating system level. You will likely build up
a complete library of Extended Events that represent what you are most
interested in monitoring about your environment. They will then become
valuable tools for years to come. We also expect forums and Microsoft to
create many templates of Extended Events to aid you in creating this
extensive library of monitoring capability.
