Monitoring for Page Splits with Extended Events
After seeing the login example in
action you may be thinking that you have yet to see Extended Events do
anything you couldn’t do just as easily with a tool like Profiler. As
you’ll see in the next example, it’s just as easy to capture
information that has not been so easy to access previously. This
example forces a clustered index to perform several page splits,
demonstrating how you can use Extended Events to monitor both the page
splits that are happening and which SQL Server statements caused them.
As with the previous example, Figure 10
shows the session configuration relevant to capturing the page split
events; how you configure the rest of the session and its event file
target is not so important. Also added, but not shown, is the database_name field; if you don’t add this you’ll just get the database_id, which may still be enough information for your troubleshooting.
After creating and starting the session, it’s
time to force some page split activity for it to capture. The following
script will set up a simple database and table before allowing you to
cause page splits on demand with an insert statement:
create database PSDemo
go
use PSDemo
go
create table t1 (ID uniqueidentifier default newid(),
val1 char(8000), val2 char(37))
go
create clustered index idx_t1 on t1(ID)
go
insert t1 (val1, val2) values (’X’,’Y’)
go
-- Repeat this insert statement as often as you want to cause splits
insert t1 (val1, val2) (select val1, val2 from t1)
go
After executing the script you’ll be
able to see just how frequently page splits occur as a database begins
to be populated, especially with a table design that was chosen to
exaggerate the frequency of page splits. An example of one of the page
split events captured is shown in Figure 11.
