New sp_Blitz® v35 Checks for Unsupported and Dangerous SQL Server Builds

News broke recently of a dangerous data loss bug in SQL Server 2012 and 2014, and Aaron Bertrand explained which patch levels are affected. It’s kinda tricky, and I’m afraid most people aren’t even going to know about the bug – let alone whether or not they’re on a bad version.

I added build number checking into the latest version of sp_Blitz® so that you can just run it. If your build has the dangerous data loss bug, you’ll get a priority 20 warning about a dangerous build. If you’re running an out-of-support version, like SQL 2012 RTM with no service packs, you’ll get a priority 20 warning about that as well.

Other changes in the last couple of versions:

Changes in v35 – June 18, 2014:

  • John Hill fixed a bug in check 134 looking for deadlocks.
  • Robert Virag improved check 19 looking for replication subscribers.
  • Russell Hart improved check 34 to avoid blocking during restores.
  • Added check 126 for priority boost enabled. It was always in the non-default configurations check, but this one is so bad we called it out.
  • Added checks 128 and 129 for unsupported builds of SQL Server.
  • Added check 127 for unneccessary backups of ReportServerTempDB.
  • Changed fill factor threshold to <80% to match sp_BlitzIndex.

Changes in v34 – April 2, 2014:

  • Jason Pritchard fixed a bug in the plan cache analysis that did not return results when analyzing for high logical reads.
  • Kirby Richter @SqlKirby fixed a bug in check 75 (t-log sizes) that failed on really big transaction log files. (Not even gonna say how big.)
  • Oleg Ivashov improved check 94 (jobs without failure emails) to exclude SSRS jobs.
  • Added @SummaryMode parameter to return only one result set per finding.
  • Added check 124 for Performance: Deadlocks Happening Daily. Looks for more than 10 deadlocks per day.
  • Moved check 121 for Performance: Serializable Locking to be lower priority (down to 100 from 10) and only triggers when more than 10 minutes of the wait have happened since startup.
  • Changed checks 107-109 for Poison Waits to have higher thresholds, now looking at more than 5 seconds per hour of server uptime. Been up for 10 hours, we look for 50 seconds, that kind of thing.

Download the latest sp_Blitz®, or head over to the introduction page. Enjoy!

Previous Post
Monitoring SQL Server Transactional Replication
Next Post
Our Senior DBA Training Class: Attendee Feedback

11 Comments. Leave new

  • Will the Windows .NET application be upgraded to this current release as well?

    • Robert – at this time, we’re kinda sunsetting that I think. It takes work for us to keep it up to date, and we haven’t heard a large user base of adoption around that, so we’ll probably be coasting that to a stop. For the latest version, check out the stored proc instead. Thanks!

      • Bummer! Not a Happy Camper!

        The application was absolutely wonderful for my situation. I think it was fantastic. The concept of not installing any stored procedures was a major plus in selling it to my “shop-master”.

        if you do completely shelve it, any chance you would “open source” it? Or maybe I would help with the up-keep.

      • I assume by your not responding to my question of “open source” or my offer to help “up-keep” the .NET version, that those are not viable options. 🙁 very saddened.

        I guess I am the only shmuck who like the .NET app. Bummer it didn’t work better for you guys. Sorry.

        Would you be willing to just share the code?

        • Robert – yeah, it’s tough because we’ve just only got so many hours in the day. We pour a ton of our time into giving free things to the community, and we have to pick and choose what we’re able to do. (As I write this blog post answer, it’s 8:30PM local time in the UK.)

    • The rule checking for databases with files on the system drive gets confused if you use mount points with the home folder on the system drive. We have more LUN’s than drive letters so we use mount points and a folder c:\.mtpoint.

  • Thanks for the script, and for getting me off my butt to set up a CMS.

    Command(s) completed successfully. (13 servers)

  • Hi Brent,
    I am a true fan of yours. But, I cannot ignore the cynical use of the word “Blitz” .

    What is next ? A stored procedure that kills all connected spids , named ” sp_holocaust” ?
    Do you get my point?
    Any chance you can rename the Blitz to something nicer like ? “sp_sql_health” ?

    • Yohan – this stored procedure is for doing a rapid, intense takeover of a SQL Server. The term is used in wars as well as sports – in American football, for example, a blitz refers to putting an intense amount of work into quickly overrunning a team and taking control in a single play. In that light, this name of sp_Blitz® is exactly right for what we’re trying to do.

      I understand your concerns, but I’m not going to rename a stored procedure just to avoid Godwin’s law.

      • Thanks for the quick reply , much appreciated.
        Nevertheless , several of our customers IT guys found the name quite offensive.

        I will try to explain them what you just explained to me .

        It’s a good thing that the term holocaust isn’t used in sports. I won’t have to worry : )


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.