Automatic Plan Correction is Enterprise Edition Only Feature in SQL Server 2017

One interesting and useful new feature in SQL Server 2017 is Automatic plan correction. This feature relies on having Query Store enabled for your database. It will look for query plan choice regressions where there has been a significant regression based on CPU time for a given query. This feature essentially automates the usage of sp_query_store_force_plan for CPU-related plan regressions. Microsoft has more details about automatic tuning here.

One important detail that isn’t easy to find about automatic plan correction is whether it is available in SQL Server 2017 Standard Edition or not. We can easily confirm whether it is Enterprise-only feature with a simple test. You can do this by trying to enable the feature on a SQL Server 2017 Standard Edition instance, and see what happens.

You use the T-SQL shown in Figure 1 to enable automatic plan correction for the current database.

image

Figure 1: T-SQL to Enable Automatic Plan Correction in SQL Server 2017

As it turns out, this feature is not available unless you are using SQL Server 2017 Enterprise Edition, as you can see in Figure 2. This is another reason that you should prefer Enterprise Edition if your budget allows it.

image

Figure 2: Error Message from SQL Server 2017 Standard Edition

Yo can learn more about this feature by watching Erin Stellato’s Pluralsight course, SQL Server: Automatic Tuning in SQL Server 2017 and Azure SQL Database. You can also read her article on SQLPerformance.com, which is Automatic Plan Correction in SQL Server.

New Intel Desktop Processor Families

Intel formally announced its 9th generation Core mainstream desktop processors on October 8, 2018 at its Fall Launch Event in New York. So far, Intel has announced three members of this new Intel desktop processor family. The prices below are the MSRP prices. Actual street prices are a currently little higher, especially for the Core i9-9900K. Supply is also a little tight so far.

Specifications

First, the Core i9-9900K has a base clock speed of 3.60 GHz, a Turbo clock speed of 5.0 GHz, and 16MB of L3 cache. Next, the Core i7-9700K has a base clock speed of 3.60 GHz, a Turbo clock speed of 4.9 GHz, and 12MB of L3 cache. Finally, the Core i5-9600K has a base clock speed of 3.70 GHz, a Turbo clock speed of 4.6 GHz, and 9MB of L3 cache. All of these processors are aimed at gaming and general desktop usage. They are competitors to AMD’s Ryzen 2xxx mainstream desktop processors.

You may have noticed that Intel has dropped hyper-threading (HT) from the Core i7 line. This was is something the Core i7 has always had, and it was one of the main differentiators over the Core i5 line in the past. The lack of HT means a loss of about 25-30% of your overall CPU capacity when you have the same number of physical cores.

All of these new Intel processors have soldered thermal interface material (rather than thermal paste) which will help with heat dissipation. This will let them run more cores at slightly higher (100-200MHz) clock speeds more often. These processors also have hardware-level mitigation for some of the Meltdown CPU exploits. This will give better performance than software or firmware mitigations.

Intel Core i9-9900K

Intel Core i9-9900K

These new processors will all work in existing Intel 300 series chipsets (with an updated BIOS).  Intel is also introducing a new Z390 chipset, which is a very slight improvement over the previous Z370 chipset, primarily with native USB 3.1 Gen 2 support and built-in 802.11ac Wi-Fi support. Here is the list of Z390 motherboards from NewEgg, while AnandTech has a roundup of Z390 motherboards here.

 High-End Desktop Processors

Intel also announced a new generation of high-end desktop (HEDT) processors, which are the Core X-Series processors. The HEDT processors use the LGA2066 socket on X299 motherboards. There are seven SKUs in this family.

These processors are designed to compete with the AMD Ryzen Threadripper HEDT processors. Unlike previous generation Intel HEDT processors, every one of the SKUs in this family support 48 PCIe 3.0 lanes.

SQL Server Diagnostic Information Queries for October 2018

This month, I have just made some minor improvements to most of the query sets.

I have a T-SQL script that you can use to check whether your instance of SQL Server has been patched to mitigate against the Spectre/Meltdown CPU vulnerability. This works for SQL Server 2008 through SQL Server 2017, for on-premises and cloud-based VM (IaaS) usage. You can get the query for this here.

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.

Rather than having a separate blog post for each version, I have just put the links for all ten major versions in this single 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 Azure SQL Database, SQL Server 2019, SQL Server 2017, SQL Server 2016 SP2, SQL Server 2016, and SQL Server 2014:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database Blank Results Spreadsheet

SQL Server 2019 Diagnostic Information Queries

SQL Server 2019 Blank Results Spreadsheet

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 Blank Results Spreadsheet

SQL Server 2016 SP2 Diagnostic Information Queries

SQL Server 2016 SP2 Blank Results Spreadsheet

SQL Server 2016 Diagnostic Information Queries

SQL Server 2016 Blank Results Spreadsheet

SQL Server 2014 Diagnostic Information Queries

SQL Server 2014 Blank Results Spreadsheet

Here are links to the most recent versions of these scripts for SQL Server 2012 and older:

Since SQL Server 2012 and older are out of Mainstream support from Microsoft (and because fewer of my customers are using these old versions of SQL Server), I am not going to be updating the scripts for these older versions of SQL Server every single month going forward.  I started this policy a while ago, and so far, I have not heard any complaints.

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

SQL Server 2008 R2 Diagnostic Information Queries

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries

SQL Server 2005 Blank Results Spreadsheet

The basic instructions for using these queries is that you should run each query in the set, one at a time (after reading the directions for that query). 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 my comments on how to interpret the results) and think about the emerging picture of what is happening on your server as you go through the complete set. I have quite a few comments and links in the script on how to interpret the results after each query.

After running each query, you need to click on the top left square of the results grid in SQL Server Management Studio (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.

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 am not planning on moving these to Github any time soon.

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, or that someone is running an incorrect version of the script for their version of SQL Server.

It is 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 four related Pluralsight courses, which are SQL Server 2017: Diagnosing Configuration Issues with DMVs, SQL Server 2014 DMV Diagnostic Queries – Part 1SQL Server 2014 DMV Diagnostic Queries – Part 2, and SQL Server 2014 DMV Diagnostic Queries – Part 3. All four of these courses are pretty short and to the point, at 106, 67, 77, and 68 minutes respectively. Listening to these four courses is really the best way to thank me for maintaining and improving these scripts…

Please let me know what you think of these queries, and whether you have any suggestions for improvements. Thanks!