I’m slowing the First Responder Kit update frequency down to once every 2 months. I know from firsthand experience working with clients that folks just can’t patch quickly enough, hahaha. Folks who want to be on the bleeding edge updates can always use the dev branch in Github, too, getting every new fix the moment it’s merged.
To get the new version:
- Download the updated FirstResponderKit.zip
- Azure Data Studio users with the First Responder Kit extension:
ctrl/command+shift+p, First Responder Kit: Import.
- PowerShell users: run Install-DbaFirstResponderKit from dbatools
- Get The Consultant Toolkit to quickly export the First Responder Kit results into an easy-to-share spreadsheet
Consultant Toolkit Changes
- Improvement: added “Buffer Pool Scan” to the list of things we show from the error log. (Thanks Erik Darling.)
I also updated it to this month’s First Responder Kit, but no changes to querymanifest.json or the spreadsheet. If you’ve customized those, no changes are necessary this month: just copy your spreadsheet and querymanifest.json into the new release’s folder.
- Improvement: new warning when target recovery interval <> 60. (#2938, thanks Erik Darling.)
- Fix: sp_Blitz installation was failing on unpatched 2012/2014/2016 builds due to last month’s Amazon RDS tweaks. (#2921, thanks Gianluca Hotz.)
- Fix: output to table wasn’t sorting by database, so if you were querying the output table and sorting by ID, you didn’t get exactly the same order as the interactive output. (#2937, thanks Johan Parlevliet.)
- Fix: only alert about the Query Store cleanup bug on SQL Server 2016, not 2019. (#2946, thanks FlatlandR.)
- Fix: avoid collation errors when pulling the #SkipChecks list from a linked server with a different collation. (#2949, thanks David Schanzer.)
- Fix: avoid arithmetic overflow errors introduced in last month’s version. (#2932, thanks Mike Halford and Erik Darling.)
- Improvement: add total thread time to wait stats views. Total thread time is the total amount of time spent executing queries, whether waiting on something or burning CPU, including parallel child threads. The Github issue is still open because we’ll be putting additional work & blogging into this over the coming weeks & months. It’s helpful when troubleshooting servers with plan cache amnesia, but I need to write more about how & why. (#2913, thanks Erik Darling.)
- Fix: enabled the Sleeping Query with Open Transactions alert. (#2922, thanks Eitan Blumin.)
- Fix: was showing multiple active backups if backup scripts were running from the context of a user database rather than master. (#2941, thanks Adrian Buckman.)
- Fix: corrected “JIndex” to “Index” in one of the warnings. (#2927)
- Fix: improve uptime measurement on Azure SQL DB. (#2933, thanks David Wiseman.)
- Fix: the statistics section now shows up even if you’re calling sp_BlitzIndex across databases. (#2954, thanks MisterZeus.)
- Improvement: new @GetOuterCommand parameter. When set to 1, shows the outer calling query. (#2887, thanks Adrian Buckman.)
- Fix: adds a trailing slash when necessary. (#2952, thanks John McCall.)
When you have questions about how the tools work, talk with the community in the #FirstResponderKit Slack channel. Be patient: it’s staffed by volunteers with day jobs. If it’s your first time in the community Slack, get started here.
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 me!) 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.
Thanks for the improvement over sp_Blitz. I’m seeing a lot of Flush Cache messages in various servers.
¿Do you think this could lead to backup problems?
We have Veeam Backup and we’re experiencing slow performance, so I’m looking for possible causes.
For personalized system advice, click Consulting at the top of the screen.
Thanks Brent 🙂