Counting the Number of Locks Acquired per Object
The final example you’ll implement uses
the histogram target to aggregate the number of locks acquired for
objects in a user database as queries are executed. You might want to
do this to help find locking hot spots in a database, but we’re using
it here because it’s an easy way to demonstrate how the histogram
target, and in this example the event filters, work.
The lock_acquired
event provides all the information needed for this example, so you
don’t need to use any global actions or additional event fields.
Instead, because SQL Server itself has a lot of background locking
activity from system processes occurring, you’ll use a filter to
exclude the locking activity you’re not interested in. The
configuration for this is shown in Figure 12.
If you are wondering where the filter values came
from, the answer is a combination of known requirements and trial and
error. One of the benefits of deploying an Extended Events session is
that it’s easy to stop the session, reconfigure it, and restart it if
it’s capturing too many or too few events (see the object_id filter setting shown in the screenshot). The database_id field was populated by executing the query select db_id(’PSDemo’).
With the filter configured, next you add the histogram target (see Figure 13).
This requires configuring some properties but you can use values
selected from drop-down lists. You can think of the “Base buckets on”
option as being like the columns in a group by clause of a select statement.
With the session running, you can then execute the insert statement from the previous example to cause locks to be acquired in your sample database:
insert t1 (val1, val2) (select val1, val2 from t1)
This produces data in the histogram that looks something like what is shown in Figure 14.
If you are wondering what the object IDs refer to in the example database, 245575913 was the actual table t1, while 261575970 was the default constraint that was bound to the ID column of table t1.
Creating Sessions Using T-SQL
Extended Events has a very comprehensive set of T-SQL
commands, which have deliberately not been covered in depth here.
Unfortunately, their complexity has been one of the main reasons why
people have not yet begun to use them, which is why this material has
focused on using the SSMS interface.
However, if you want to start using the T-SQL
Extended Events commands, the SSMS interface can help you get started
by scripting out a session after you define it. You can do this using
the Script button, which you are probably familiar with from other
parts of SSMS; however, it’s shown in Figure 15.
For example, a session that captures all the logout events is shown here as a T-SQL create script:
CREATE EVENT SESSION [LogoutEvents] ON SERVER
ADD EVENT sqlserver.logout(ACTION(sqlserver.client_app_name,
sqlserver.client_hostname,sqlserver.nt_username))
ADD TARGET package0.event_file(SET filename=N'C:\XELogs\LogoutEvents.xel')
WITH (STARTUP_STATE=ON)
GO
