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.
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.
Yeah, the year 2016.
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?
I mean the year 2016, not the version.
The link: https://www.brentozar.com/go/freememory
from sp_Blitz takes you to the home page. I installed the newest version this morning.
Doh! I happened to be working on that page while you sent that in, hahaha! It’s ready now.
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.
Toby – well, you know what they say – you can’t believe everything you read.
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.
cheers
James
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??.
Thanks.
Armando – unfortunately, SQL Server 2005 is no longer under support. Support ended for 2005 back in April.
“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?
Kaj – new insights. You’re best off running the new version of the scripts at all times. Enjoy, and hope our work can help make your job better!
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?
Yep, for the year 2016.
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?
Regards
Andrew – make sure to read the explanation page carefully:
https://www.brentozar.com/blitz/schedulers-disabled/
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.
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.
Regards,
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. 😉
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.
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.
Sure — try using it on SQL Server 2016?