I revised a number of the queries this month in all five versions of the script.
Here are the current query counts for each version:
SQL Server 2014 72 Queries
SQL Server 2012 69 Queries
SQL Server 2008 R2 65 Queries
SQL Server 2008 59 Queries
SQL Server 2005 51 Queries
Rather than having a separate blog post for each version, I have just put the links for all five major versions in this single post. There are two separate links for each version. The first one on the top left is the actual query script, and the one below on the right is the matching blank results spreadsheet.
SQL Server 2005 Diagnostic Information Queries
SQL Server 2005 Blank Results
SQL Server 2008 Diagnostic Information Queries
SQL Server 2008 Blank Results
SQL Server 2008 R2 Diagnostic Information Queries
SQL Server 2008 R2 Blank Results
SQL Server 2012 Diagnostic Information Queries
SQL Server 2012 Blank Results
SQL Server 2014 Diagnostic Information Queries
SQL Server 2014 Blank Results
The basic idea is that you should run each query in the set, one at a time (after reading the directions). It is not really a good idea to simply run the entire batch in one shot, especially the first time you run these queries on a particular server, since some of these queries can take some time to run, depending on your workload and hardware. I also think it is very helpful to run each query, look at the results and think about the emerging picture of what is happening on your server as you go through the complete set.
You need to click on the top left square of the results grid in SSMS to select all of the results, and then right-click and select “Copy with Headers” to copy all of the results, including the column headers to the Windows clipboard. Then you paste the results into the matching tab in the blank results spreadsheet. There are also some comments on how to interpret the results after each query.
About half of the queries are instance specific and about half are database specific, so you will want to make sure you are connected to a database that you are concerned about instead of the master system database. Running the database-specific queries while being connected to the master database is a very common mistake that I see people making when they run these queries.
Note: These queries are stored on Dropbox. I occasionally get reports that the links to the queries and blank results spreadsheets do not work, which is most likely because Dropbox is blocked wherever people are trying to connect.
I also occasionally get reports that some of the queries simply don’t work. This usually turns out to be an issue where people have some of their user databases in 80 compatibility mode, which breaks many DMV queries.
It is also very important that you are running the correct version of the script that matches the major version of SQL Server that you are running. There is an initial query in each script that tries to confirm that you are using the correct version of the script for your version of SQL Server. If you are not using the correct version of these queries for your version of SQL Server, some of the queries are not going to work correctly.
If you want to understand how to better run and interpret these queries, you should consider listening to my two latest Pluralsight courses, which are SQL Server 2014 DMV Diagnostic Queries – Part 1 and SQL Server 2014 DMV Diagnostic Queries – Part 2. Both of these courses are pretty short and to the point, at 67 and 77 minutes respectively. Part 3 of the series has been recorded, and will probably be published in February 2015.
Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!
3 thoughts on “SQL Server Diagnostic Information Queries for December 2014”
Glenn,
I have been using the what database is using the CPU and I/O queries for sometime now but just came upon a strange situation. We patch our servers once a month so the servers get restarted and the DMV’s get cleared out. Because of this I collect the numbers between the restarts but also take them once an hour looking for unusual database activity. This week I had a surprise. The numbers taken at one hour showed big CPU numbers against one database and then the next hour its usage had gone way down. It took me a little while to see what was happening. The numbers come from sys.dm_exec_query_stats and sys.dm_exec_plan_attributes. These all come from the cached query plans so some plans must have been flushed from the plan cache or maybe replaced with newer versions that no longer had the high CPU numbers against it. This was against an SQL2012 SP2 server.
I’ll just have to watch the intermediate numbers more closely and see if this happens often.
Chris
In short, they are awesome!