This month, 15 community folks contributed code – I think that’s an all-time high for a single month’s release! Good work, y’all. Thanks for payin’ it forward. The bad news is that they’re almost all bug fixes, hahaha. I do love that, though – given enough eyeballs, all bugs are shallow.
If you’re working directly with the releases on Github, note that the “master” branch has been renamed to “main” instead.
- 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
- Download the updated Consultant Toolkit in your account
- EU customers: check your email for the updated version from Gumroad, our European distributor
Consultant Toolkit Changes
Updated the First Responder Kit with this month’s script updates, plus:
- Improvement: the config file now lets you specify default values for the –upload and –deepdive command line switches. This way, you can pass even less instructions on to your clients – just have ’em run the utility, and you get their diagnostic data in your Amazon S3 bucket within minutes. Read the auto-upload documentation for more details.
- Improvement: new –applicationintent parameter lets you connect to readable secondaries in an AG. Possible options are ReadWrite or ReadOnly.
- Fix: no arithmetic overflow even if you have truly ginormous bigint sp_BlitzCache metrics. (#2270.)
- Improvement: the installation scripts create the SqlServerVersions table if it doesn’t exist, and repopulate it. (#2429, thanks Curtis Browne.)
- Fix: Update descriptions of operating systems and no longer call Windows 2012 & R2 “pretty modern.” (#2418, thanks Randolph West.)
- Fix: when alerting about tables in the master database, ignore the Dynamics NAV license table. (#2426, thanks Johan Parlevliet.)
- Maybe fix: possible arithmetic overflow when checking for many duplicate plans in the cache. Not entirely sure whether this actually fixes it, though, because I couldn’t reproduce it. (#2425, thanks smcnaughton, Randolph West, and Santi Swarup Choudhury.)
- Improvement: now runs faster if @OutputType = ‘NONE’. (#2423, thanks Jefferson Elias.)
- Improvement: new check for >10% of your memory being used by the USERSTORE_TOKENPERM cache. (#2134)
- Fix: last month’s new update-stats check would fail if you had a LOT of stats updates at once, like, well, an update-stats job. Doh! Now we just show the first 4,000 characters of updated stats, sorted by rows in the table descending, so you can get a rough idea of when you had big churn. (#2409, thanks CJR aka camaro322hp.)
- Fix: remove Page Life Expectancy warning. It’s a bad metric to monitor in the year 2020. (#2433)
- Fix: no longer alert on >10000x cardinality UNDER-estimations because they’re false alarms when the query just started and hasn’t retrieved data yet. (#2438, thanks Nicklas Bjälemark.)
- Fix: skips last month’s new update-stats check when you have >20 databases. (#2439, thanks Will McCardell.)
- Improvement: In-Memory OLTP indexes now have a call to sp_BlitzInMemoryOLTP in the “More Info” column. (#296)
- Improvement: in the readme, documented the levels of support for specialized index types (columnstore, graph, spatial, temporal tables.) I’m not really actively adding support for those, but just wanted to make it clear in the documentation that they show up in the results, just with varying levels of details. For example, the sizes of most of ’em aren’t shown.
- Fix: for disabled indexes, the “Create TSQL” column now shows a create rather than a drop. (#2447, thanks Filip Cornelissen.)
- Fix: handles long database & schema names when creating the output tables. (#2421, thanks Jefferson Elias.)
- Fix: adds compatibility with Azure SQL DB by avoiding querying sysjobs. (#2435, thanks Jacob Golden.)
- Improvement: file paths now take a comma-delimited list of paths for striped files. (#2180, thanks CubsRep.)
- Fix: won’t error out if you specify both @StopAt and @OnlyLogsAfter at the same time. (#2348, thanks Greg Dodd.)
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.
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.