sp_Blitz® v44: Reorganized and Reprioritized Results.

SQL Server

Angie Walker, our new Triage Specialist, had the fun experience of sitting in and watching several of our SQL Critical Care® engagements. When I asked her if she noticed any patterns or ways we could improve, she said, “The order of sp_Blitz’s output needs to be reworked for 2016. There’s some stuff at the top that isn’t really high-priority anymore, and there’s stuff that used to be low priority but is now pretty important.”

She was totally right – and that’s what I focused on for this month’s version.

We moved some of the findings into Monitoring, some into File Configuration, set less ambitious thresholds for storage, and removed some things that just don’t matter as much these days.

Our goal is to give you a really actionable set of findings – when you run sp_Blitz®, I want you to be able to say, “Here’s the next things I need to go work on fixing in my environment.”

Grab it and the newly updated sp_BlitzFirst® in our First Responder Kit.

Previous Post
Meet Our Next Consultant: Tara Kizer
Next Post
How to Talk People Out of the SA Account, Option 1

25 Comments. Leave new

  • I know this goes without saying (but in writ.. Aha! Loophole) that when you say ” reworked for 2016″, I assume you mean for “the year 2016”, rather than “SQL 2016”, since the latter is still in early preview stages.

  • Brian Averitt
    January 7, 2016 12:35 pm

    Is the output the same for all versions (order, thresholds, etc) or is it based on what version of SQL it find it is executed on? So if I run it on 2008 R2 (yes, we have a ton of these still) will the results be skewed at all since it was revamped with 2016 in mind?

  • The link: http://BrentOzar.com/go/freememory
    from sp_Blitz takes you to the home page. I installed the newest version this morning.

  • I thought sp_Blitz v46 was out (see https://www.brentozar.com/blitz/), but according to the Change Log and the first responders kit it’s v45.

  • Hey Brent,

    The new version doesn’t work on SQL 2005 any more, fails with “Invalid column name ‘compressed_backup_size'”. This is caused by check 116 (default backup compression) as that column doesn’t exist in older versions of the backupset table in msdb.


    • James – sorry about that! Grab the current version, v45, which fixed that a few days ago. Enjoy!

      • Hello Brent.-

        I know this is an old post but i am keep getting this error in version 51 on SQL 2005.
        “Msg 207, Level 16, State 1, Procedure sp_Blitz, Line 737
        Invalid column name ‘compressed_backup_size’.”

        is this related or i am missing something??.


  • “There’s some stuff at the top that isn’t really high-priority anymore, and there’s stuff that used to be low priority but is now pretty important.”

    What has prompted the change in priority? New server hardware? Amount of memory nowadays? New SQL Server versions? New insights? The quoted statement really calls for an elaboration.

    So what if we run on old equipment, old windows versions, old SQL Server versions. Will the new version of the script still produce more correct answers?

  • Aha! Loophole) that when you say ” reworked for 2016?, I assume you mean for “the year 2016”, rather than “SQL 2016”, since the latter is still in early preview stages. Where is this information?

  • Andrew Bassitt
    April 13, 2016 3:31 am

    Hi Brent,

    Absolutely love your free tools and we use them regularly!

    Just a question regarding the output from sp_Blitz.
    The output presented us with the following information:
    * CPU Schedulers Offline
    * Memory Nodes Offline

    I read through your help and explanations, but I couldn’t figure out the cause on our systems.

    The only thing I can see is that we’ve limited SQL to use a fixed amount of memory (having set a minimum and also maximum memory) and we’ve configured MAXDOP to 40 from the default. (we run 40 dual core CPUs)

    Might these two options trigger the above warnings?


    • Andrew – make sure to read the explanation page carefully:


      The root cause is listed on that page. It’s either affinity masking, licensing, or misconfigured virtual cores in VMware. If you’d like consulting help interpreting the results, give us an email up at the top of the page.

      • Andy Bassitt
        April 13, 2016 3:54 am

        Thanks Brent,

        I’ll revisit the licensing side of things as, by a process of elimination, that’s all it can be. I presumed that Windows 2012 R2 Standard would be able to use all the cores. I guess not. (SQL shouldn’t be a problem as it’s an enterprise license so can use all that the OS can support).

        Will mail you if we cant figure it out.


        • Andy – it’s really super-important that you read carefully. On that page, we explain scenarios where SQL Server Enterprise Edition doesn’t use more than a certain number of cores. Seriously, give it a good read – it’s not a long page.

          Reading: it really is fundamental. 😉

          • Andy Bassitt
            April 13, 2016 4:24 am

            Y’know what….. Ignore me. 🙂

            I took someone’s word on something rather than thinking for myself. (more fool me).

            Thanks for your patience at what must be ridiculously early in the morning over there!

          • 😀 5:25AM at the moment, prepping for a class today in Newark.

          • Andy Bassitt
            April 13, 2016 4:31 am

            Good grief!
            Well, I hope it goes well… hopefully you have some decent coffee to keep you going!

  • I am getting below error while executing the SP, could you please help me to fix it…

    Sorry, sp_BlitzQueryStore doesn’t work on versions of SQL prior to 2016, or Azure Database compatibility < 130.


Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.