SQL Server Community Tools: How I Use sp_BlitzFirst

Posted on by Erik Darling

1 of 3

This post is a pretty easy one, because there aren’t a ton of secret ways to run sp_BlitzFirst.

The big value for this one is you can either:

  • Run it to get everything since the server was last restarted (or some noodlehead cleared things out)
  • Run it to sample a period of time to see what happens cumulatively during a workload

Sure, there are times when getting everything since startup is enough, but if the server has been up for hundreds or thousands of hours then it’s way less valuable:

  • Some really bad stuff might have been generated a long time ago and are irrelevant now
  • Some really bad stuff just started happening and might look insignificant compared to uptime

Why do servers end up not getting patched or restarted for that long? Let me count the ways!

  • Admins not patching because ???
  • Admins not patching because they’re scared of the CU servicing model (I don’t blame them, here)
  • Admins not patching because “everything is fine”
  • Admins not patching because they are lazy and bad at their job

I could go on, but I respect horses too much.

2 of 3

To see what a server has been up to since last reboot (or some noodlehead cleared things out), all you have to do is this:

EXEC sp_BlitzFirst
    @SinceStartup = 1;

This runs quickly, and hands you back a few different things:

  • Wait stats
  • File stats
  • Perfmon counters

I’m pretty guilty of only looking at wait stats here, and only giving the other stuff a cursory glance.

For file stats, I look for really high read or write latency, and for perfmon counters I tend to look at batch requests, compilations, and recompiles.

Beyond that, anything else I might care about is stuff I’m going to dig into with other tools that pull out more detail.

I’m not complaining — I could write in more detailed checks here — they just wouldn’t make sense at this level of analysis.

3 of 3

The other way I generally run sp_BlitzFirst is to look at what’s currently happening on a server.

Like I said, the longer a server is up the more things get blurred and blended into crazy numbers.

Running the procedure like this does require an extra parameter:

EXEC sp_BlitzFirst
    @Seconds = 10,
    @ExpertMode = 1;

There are three great things about this:

  • You can make a joke about how the extra parameter makes you a SQL Server expert
  • The longer you run it for, the more time you have to look at email and twitter without it looking like you’re not paying attention
  • It returns a nice section of warnings from any blaring issues that get detected during the sample

You get back all the same stuff as @SinceStartup, too, but only for the window you look at things in.

That can be super helpful for isolating current problems.

Thanks for reading!

Going Further

If this is the kind of SQL Server stuff you love learning about, you’ll love my training. I’m offering a 75% discount to my blog readers if you click from here. I’m also available for consulting if you just don’t have time for that, and need to solve database performance problems quickly. You can also get a quick, low cost health check with no phone time required.

Related Posts