These are my SQL Server Diagnostic Information Queries for October 2021, aka my DMV Diagnostic Queries. They allow you to get a very comprehensive view of the configuration and performance of your SQL Server instance in a short amount of time. These are my SQL Server Diagnostic Information Queries for October 2021.
There are separate versions of these T-SQL queries for SQL Server 2005 through SQL Server 2019. I also have separate versions for SQL Managed Instance and Azure SQL Database. My diagnostic queries have been used by many people around the world since 2009. I make regular improvements to these queries each month.
This month, I have made improvements to Lock Waits query, adding two new columns, index_lock_promotion_attempt_count and index_lock_promotion_count, to help better understand what is happening with row locks and page locks being promoted to table locks.
I have also added a new database-specific query called Last Good CheckDB that gives you the date and time of the last good CheckDB that has been run on the current database. If DBCC CHECKDB has not been run on a database, 1900-01-01 00:00:00.000 is returned. This query was inspired by a request from Daniel Maenle. Thanks!
As always, I have made additional small improvements and corrections to all of the versions of these queries.
Making YouTube videos about these queries has forced me to look at some of them with a new perspective. This video walks through all of the Diagnostic Information queries from the SQL Server 2019 set.
BTW, I often make additional minor updates to the queries periodically during the month, so if you are in doubt, downloading the latest version is always a good idea. They are always available from my Resources page.
Rather than having a separate blog post for each version, I have just put the links for all eleven major versions in this post. There are two separate links for each version. The first one on the top left is the actual diagnostic query script, and the one below on the right is the matching blank results spreadsheet, with labeled tabs that correspond to each query in the set.
Here are links to the latest versions of these queries for SQL Managed Instance, Azure SQL Database, and all available versions of SQL Server:
Azure Diagnostic Queries
- SQL Managed Instance Diagnostic Information Queries
- Azure SQL Database Diagnostic Information Queries
SQL Server Diagnostic Queries
- SQL Server 2019 Diagnostic Information Queries
- SQL Server 2017 Diagnostic Information Queries
Legacy SQL Server Diagnostic Queries
- SQL Server 2016 SP2 Diagnostic Information Queries
- SQL Server 2016 Diagnostic Information Queries
- SQL Server 2014 Diagnostic Information Queries
- SQL Server 2012 Diagnostic Information Queries
- SQL Server 2008 R2 Diagnostic Information Queries
- SQL Server 2008 Diagnostic Information Queries
- SQL Server 2005 Diagnostic Information Queries
The basic instructions for manually running these queries is that you should run each query in the set, one at a time. You should read the directions for each query and my comments on how to interpret the results. It is not a good idea to simply run the entire batch in one shot. This is especially true the first time you run these queries on a particular server. Some of these queries can take some time to run, depending on your workload and hardware.
It is very useful to run each query, look at the results and think about the emerging picture of what is happening on your server. I have quite a few comments and links in the script on how to interpret the results after each query.
Saving the Results
After running each query, you click on the top left square of the results grid in SQL Server Management Studio (SSMS) to select all of the results. Next, you right-click and select “Copy with Headers” to copy the results, including the column headers to the Windows clipboard. Finally, you paste the results into the matching tab in the blank results spreadsheet.
About half of the queries are instance specific and about half are database specific. Because of this, make sure you are connected to a database that you are concerned about! Make sure you are not connected to the master system database. Running the database-specific queries while being connected to the master database is a very common mistake. As a result, I often see people make this mistake when they run these queries.
Note: These queries are stored on Dropbox. I occasionally hear that the links to the queries and blank results spreadsheets don’t work. This is usually because Dropbox is blocked where someone is trying to connect. I am not planning on moving these to Github any time soon, but I could change my mind.
Unfortunately, I sometimes get reports that some of the queries simply don’t work. This usually happens with an incorrect version of the script for the version of SQL Server. Sometimes, it turns out to be an issue where people have some of their user databases in 80 compatibility mode. This will break many DMV queries. This is less common than it used to be, since more people are on newer versions of SQL Server that don’t support 80 compatibility mode.
It is very important that you are running the script that matches the version of SQL Server that you are running. There is an initial query in each script that confirms that you are using the correct version of the script. If you are not using the correct version of these queries, you will have problems.
Checking Spectre/Meltdown Status
In addition, I have a T-SQL script to check whether an instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This query works for SQL Server 2008 through SQL Server 2019, for on-premises and cloud-based VM (IaaS) usage. SQL Server 2019 actually has this fix in all builds, so you don’t have to check SQL Server 2019 instances. You can get the query for this here.
Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!
I recorded a PASS Summit session in October of 2020 featuring the Juypter notebook version of these queries. The video for that is embedded below.
If you want to understand how to better interpret these queries, you should listen to my YouTube videos that walk through how to interpret the results of each of these queries.
These are the ones I have completed so far:
- SQL Server Diagnostic Queries Part 1
- SQL Server Diagnostic Queries Part 2
- SQL Server Diagnostic Queries Part 3
- SQL Server Diagnostic Queries Part 4
- SQL Server Diagnostic Queries Part 5
- SQL Server Diagnostic Queries Part 6
- SQL Server Diagnostic Queries Part 7
- SQL Server Diagnostic Queries Part 8
- SQL Server Diagnostic Queries Part 9
- SQL Server Diagnostic Queries Part 10
- SQL Server Diagnostic Queries Part 11
- SQL Server Diagnostic Queries Part 12
- SQL Server Diagnostic Queries Part 13
- SQL Server Diagnostic Queries Part 14
Watching and “liking” these videos is really the best way to thank me for maintaining and improving these scripts…
If you have any questions about this post, please ask me here in the comments or on Twitter. I am pretty active on Twitter as GlennAlanBerry. Thanks for reading!
1 thought on “SQL Server Diagnostic Information Queries for October 2021”
thanks, very usesul 🙂
If I may, according to Microsoft’s documentation, locks are escalated straight from rows to table, never page.
“Lock escalation cannot occur if a different SPID is currently holding an incompatible table lock. Lock escalation always escalates to a table lock, and never to a page lock.”