T*m* f*r An*th*r F*rst R*spond*r K*t R*l**s*.

All joking aside! A big thank you goes out to a few people this go around:

@jadarnel27 for not only contributing a bunch of Super Professional T-SQL, but also for writing a web scraping application to compile a list of current SQL Server versions.

@nedotter @ktaranov and Aleksey Nagorskiy for putting together a brand new stored proc: sp_BlitzInMemoryOLTP, to examine your In Memory stuff. For documentation on that, head on over to http://nedotter.com/archive/2018/06/new-kid-on-the-block-sp_blitzinmemoryoltp/.

@EmanueleMeazzo has done an outstanding job working on both PowerBI and the backing queries in sp_BlitzFirst lately. I’m amazed anyone has this much patience — both for dealing with us, and with PowerBI.

Now that we’re done being all emotional, let’s get to the nitty gritty.

You can download the updated FirstResponderKit.zip here.

sp_Blitz Improvements

#1565: When determining processor speed and power settings, we weren’t accounting for people being on AMDs. I know, I know. Who would ever do that to their SQL Server? (@jadarnel27)
#1585: @rsocol let us know that we weren’t ignoring DBCC USEROPTIONS. Consider it done!
#1592: @Tisit let us know about some row duplication when checking for procs with recompile. This has been fixed with the healing power of DISTINCT.
#1606: @CCUMan let us know about an arithmetic overflow issue they were hitting. Darn milliseconds.
#1603: Microsoft announced some new ignorable AG waits, along with some other surprises and gotchas around AGs:

When the host server has 32 or more CPU cores, each database will occupy 16 parallel redo worker threads and one helper worker thread. It means that all databases starting with the 7th database (ordered by database id ascending) that has joined availability group it will be in single thread redo or serial redo irrespective which database has actual redo workload. If a SQL Server Instance has a number of databases, and it is desired for a particular database to run under parallel redo model, the database creation order needs to be considered. Same idea can be applied to force a database always runs in serial redo model as well.

sp_BlitzCache Improvements

#1559: Fixed an issue where unsafe XML characters weren’t displaying correctly in clickable columns
#1561 A friendly user finally helped us track down when some data was causing truncation errors when looking at cached paramaters. Blame it on CASE expressions in WHERE clauses.
#1564 & #1578: SET OPTIONS for stored procs and statements are now logged in the cached execution parameter clickable column.
#1575: Fixed math for tallying proc and statement costs
#1594: @tompazourek hates leading spaces. He let us know by changing the SUBSTRING arguments for the warnings column

sp_BlitzFirst Improvements

#1557: When we show CPU usage from ring buffers, we were only showing the most recent one. Now we show you all of them so you can see if something went terribly wrong recently.
#1581: We fixed sp_BlitzFirst to only alert when only > 20GB of memory is free. Thanks to @dbadave87for letting us know about that one!
#1586: @EmanueleMeazzo fixed a little bug around dynamic view creation, reported by @smcnaughton. Yay, we didn’t have to do any work.
#1603: Same as in sp_Blitz.

sp_BlitzIndex Improvements

#1588: More clear wording around what aggressive index warnings are and mean, and how to approach fixing them.

sp_BlitzQueryStore Improvements

Just about the same stuff as sp_BlitzCache.

PowerBI

#1579: Standard deviations! @EmanueleMeazzo added a couple new pages to help you figure out if any current metrics are much higher than usual. This is badass.

sp_BlitzLock

@jadarnel27 added some great stuff:
#1572: Added deadlock priority to the results
#1573: Filtered out Heaps from deadlock index info.
#1597: Added the entire deadlock graph for easy distribution

I’m starting to think Josh has a deadlock problem.

sp_BlitzInMemoryOLTP Improvements

Initial release! Mazel tov! This is a soft release, meaning it’s not in any of the bulk installer scripts yet. After you nice people have had some time to kick it around, we’ll throw it in there as well.

sp_BlitzWho Improvements

Nothing this time around

sp_DatabaseRestore Improvements

Nothing this time around

sp_BlitzBackups Improvements

Nothing this time around

sp_AllNightLog and sp_AllNightLog_Setup Improvements

Nothing this time around

sp_foreachdb Improvements

Nothing this time around

For Support

When you have questions about how the tools work, talk with the community in the #FirstResponderKit Slack channel. If you need a free invite, hit SQLslack.com. Be patient – it’s staffed with volunteers who have day jobs, heh.

When you find a bug or want something changed, read the contributing.md file.

When you have a question about what the scripts found, first make sure you read the “More Details” URL for any warning you find. We put a lot of work into documentation, and we wouldn’t want someone to yell at you to go read the fine manual. After that, when you’ve still got questions about how something works in SQL Server, post a question at DBA.StackExchange.com and the community (that includes us!) will help. Include exact errors and any applicable screenshots, your SQL Server version number (including the build #), and the version of the tool you’re working with.

You can download the updated FirstResponderKit.zip here.