Extended Events, the system_health Session, and Waits

Home / SQL Server 2008 / Extended Events, the system_health Session, and Waits

I advocate for, use, document, teach, and just downright love, Extended Events. They are so much better than the old Trace Events (aka, Profiler) that it’s sometimes difficult to keep from just gushing. Let’s talk about a common situation that you’re going to run into on your servers all the time and how you can put Extended Events to work to help you, without actually doing any work at all.

What’s that? Be lazy and get rewards? Yes.

The Extended Events system_health Session

On your servers, any of them that are SQL Server 2008 or newer, right now, unless you’ve performed actions to prevent this, you’re running the Extended Events system_health session. It’s just happening, currently, on all your servers. Nothing you need to do about it at all. I’ll be a lot of you never even knew it was there.

If you follow the link you can see all the various types of information being gathered by the Extended Event system_health session. I won’t detail all of it here. Let me just provide a little context around how the session works. First and foremost, similar to the error log, this session consists of four files, each 5mb in size, rolling over as they get filled. For systems with a very high degree of activity, that means the information here may only be hours old. However, for most of us, this provides days, if not weeks worth of information about the behavior of your system.

You’ll need to know where the files are located so that we can query them or open them up in the Live Data window. Here’s a simple query that will give you the path on any system:

Now there are a ton of reasons why you should be taking advantage of the system_health session (deadlocks for example), but I’m going to focus on one, blocks.

Waits In The system_health Session

To see this information in action, we can set up a really simple query. Run this from two different query windows and let it sit for about 45 seconds or so (it only needs 30, but for our purposes, add a little padding):

After a little while, roll back both scripts. Then, we can run this script to take a look at the system_health information specifically on the waits caused by these two queries blocking one another:

The results on my system look like this:

You have the query, the wait_resource, the duration, in short, everything you need to start identifying why you had excessive blocking on one of your servers and all you had to do was reach out and grab it.

I’ll leave parsing the XML to others (check out this book, just starting to read it).


Really, there was a query that ran unusually long yesterday? I wonder if it was blocked and waiting on resources? Let me take a quick look at the Extended Events system_health session. It really is that easy. This is a free, easily accessed resource that is available to you right now. Please, use it.

Want to see a WHOLE bunch of other tricks and methods with Extended Events as well as a slew of other tools for dealing with SQL Server performance? I’m putting on an all day seminar in various locations. Please follow the links below to take advantage of this great learning and sharing opportunity:

For SQLSaturday Indianapolis (and my first time speaking in Indiana) on August 10, 2018. Please go here to sign up.

I’ll be at SQLSaturday Sioux Falls (and my first time speaking in South Dakota) on August 18, 2018. Please sign up here.

For SQLSaturday Oslo on August 31, 2018. Click here right now to register.


OK, fine, but what do you think?

This site uses Akismet to reduce spam. Learn how your comment data is processed.