SQL Server 2014 Archives - Glenn Berry

The Importance of Database Compatibility Level in SQL Server

Glenn Berry — Mon, 14 Jan 2019 22:55:45 +0000

(New: we’ve published a range of SQL Server interview candidate screening assessments with our partner Kandio, so you can avoid hiring an ‘expert’ who ends up causing problems. Check them out here.)

Prior to SQL Server 2014, the database compatibility level of your user databases was not typically an important property that you had to be concerned with, at least from a performance perspective. Unlike the database file level (which gets automatically upgraded when you restore or attach a down-level database to an instance running a newer version of SQL Server, and which can never go back to the lower level), the database compatibility level can be changed to any supported level with a simple ALTER DATABASE SET COMPATIBILITY LEVEL = xxx command.

You are not stuck at any particular supported database compatibility level, and you can change the compatibility level back to any supported level that you wish. In many cases, most user databases never had their compatibility levels changed after a migration to a new version of SQL Server. This usually didn’t cause any issues unless you actually needed a new feature that was enabled by the latest database compatibility level.

With SQL Server 2012 and older, the database compatibility level was mainly used to control whether new features introduced with a particular version of SQL Server were enabled or not and whether non-supported old features were disabled or not. The database compatibility level was also used as a method to maintain better backwards application compatibility with old versions of SQL Server. If you didn’t have time to do full regression testing with the newest compatibility level, you could just use the previous compatibility level until you could test and modify your applications if needed.

Table 1 shows the major versions of SQL Server and their default and supported database compatibility levels.

SQL Server Version Database Engine Version Default Compatibility Level Supported Compatibility Levels

SQL Server 2019 15 150 150, 140, 130, 120, 110, 100

SQL Server 2017 14 140 140, 130, 120, 110, 100

SQL Server 2016 13 130 130, 120, 110, 100

SQL Server 2014 12 120 120, 110, 100

SQL Server 2012 11 110 110, 100, 90

SQL Server 2008 R2 10.5 100 100, 90, 80

SQL Server 2008 10 100 100, 90, 80

SQL Server 2005 9 90 90, 80

SQL Server 2000 8 80 80

Table 1: SQL Server Versions and Supported Compatibility Levels

New Database Creation

When you create a new user database in SQL Server, the database compatibility level will be set to the default compatibility level for that version of SQL Server. So for example, a new user database that is created in SQL Server 2017 will have a database compatibility level of 140. The exception to this is if you have changed the compatibility level of the model system database to a different supported database compatibility level, then a new user database will inherit its database compatibility level from the model database.

Database Restore or Attach

If you restore a full database backup that was taken on an older version of SQL Server to an instance that is running a newer version of SQL Server, then the database compatibility level will stay the same as it was on the older version of SQL Server, unless the old database compatibility level is lower than the minimum supported database compatibility level for the newer version of SQL Server. In that case, the database compatibility level will be changed to the lowest supported version for the newer version of SQL Server.

For example, if you were to restore a SQL Server 2005 database backup to a SQL Server 2017 instance, the database compatibility level for that restored database would be changed to 100. You will get the same behavior if you detach a database from an older version of SQL Server, and then attach it to a newer version of SQL Server.

This general behavior is not new, but what is new and important is what else happens when you change a user database to database compatibility level 120 or newer. These additional changes, that can have a huge impact on performance, don’t seem to be widely known and understood in the wider SQL Server community. I still see many database professionals and their organizations just doing what I call “blind upgrades” where they go from SQL Server 2012 or older to SQL Server 2014 or newer (especially SQL Server 2016 and SQL Server 2017), where they don’t do any serious performance regression testing to understand how their workload will behave on the new native compatibility level and whether the additional configuration options that are available will have a positive effect or not.

Database Compatibility Level 120

This was when the “new” cardinality estimator (CE) was introduced. In many cases, most of your queries ran faster when using the new cardinality estimator, but it was fairly common to run into some queries that had major performance regressions with the new cardinality estimator. Using database compatibility level 120 means that you will be using the “new” CE unless you use an instance-wide trace flag or a query-level query hint to override it.

Joe Sack wrote the classic whitepaper “Optimizing Your Query Plans with the SQL Server 2014 Cardinality Estimator” that explains the background and behavior of this change back in April of 2014. If you saw performance regressions on some queries with the new CE, SQL Server 2014 did not have that many options for alleviating the performance issues caused by the new CE. Joe’s whitepaper covers those options in great detail, but essentially, you were limited to instance-level trace flags or query-level query hints to control which cardinality estimator was used by the query optimizer, unless you wanted to revert back to database compatibility level 110 or lower.

The reason I called it the “new” CE in quotes is because there is now no single “new” CE. Each new version of SQL Server since SQL Server 2014 has CE and query optimizer changes tied to the database compatibility level. The new, more accurate terminology that is relevant on SQL Server 2016 and newer is CE120 for compatibility level 120, CE130 for for compatibility level 130, CE140 for for compatibility level 140, and CE150 for for compatibility level 150.

Database Compatibility Level 130

When you are on SQL Server 2016 or newer, using database compatibility level 130 will use CE130 by default, and will enable a number of other performance related changes. The effects of global trace flags 1117, 1118, and 2371 are enabled with database compatibility level 130. You will also get the effect of global trace flag 4199 for all query optimizer hotfixes that were released before SQL Server 2016 RTM.

SQL Server 2016 also introduced database scoped configuration options, which give you the ability to control some behaviors that were formerly configured at the instance level, using an ALTER DATABASE SCOPED CONFIGURATION command. The two most relevant database scoped configuration options for this discussion are LEGACY_CARDINALITY ESTIMATION and QUERY_OPTIMIZER_HOTFIXES.

LEGACY_CARDINALITY ESTIMATION enables the legacy CE (CE70) regardless of the database compatibility level setting. It is equivalent to trace flag 9481, but it only affects the database in question, not the entire instance. It allows you to set the database compatibility level to 130 in order to get the other functional and performance benefits, but use the legacy CE database-wide (unless overridden by a query-level query hint).

The QUERY_OPTIMIZER_HOTFIXES option is equivalent to trace flag 4199 at the database level. SQL Server 2016 will enable all query optimizer hotfixes before SQL Server 2016 RTM when you use the 130 database compatibility level (without enabling trace flag 4199). If you do enable TF 4199 or enable QUERY_OPTIMIZER_HOTFIXES, you will also get all of the query optimizer hotfixes that were released after SQL Server 2016 RTM.

SQL Server 2016 SP1 also introduced the USE HINT query hints that are easier to use and understand than the older QUERYTRACEON query hints that you had to use in SQL Server 2014 and older. This gives you even more fine-grained control over optimizer behavior that is related to database compatibility level and the version of the cardinality estimator that is being used. You can query sys.dm_exec_valid_use_hints to get a list of valid USE HINT names for the exact build of SQL Server that you are running.

Database Compatibility Level 140

When you are on SQL Server 2017 or newer, using database compatibility level 140 will use CE140 by default. You also get all of the other performance related changes from 130, plus new ones as detailed here. SQL Server 2017 introduced the new adaptive query processing features, and they are enabled by default when you are using database compatibility level 140. These include batch mode memory grant feedback, batch mode adaptive joins, and interleaved execution.

Database Compatibility Level 150

When you are on SQL Server 2019 or newer, using database compatibility level 150 will use CE150 by default. You also get all of the other performance related changes from 130 and 140, plus new ones as detailed here. SQL Server 2019 is adding even more performance improvements and behavior changes that are enabled by default when a database is using compatibility mode 150. A prime example is scalar UDF inlining, which automatically inline many scalar UDF functions in your user databases. This may be one of the most important performance improvements for some workloads.

Another example is the intelligent query processing feature, which is a superset of the adaptive query processing feature in SQL Server 2017. New features include table variable deferred compilation, approximate query processing, and batch mode on rowstore.

There are also sixteen new database scoped configuration options (as of CTP 2.2) that give you database-level control of more items that are also affected by trace flags or the database compatibility level. It gives you even more fine-grained control of these higher level changes that are enabled by default with database compatibility level 150.

Conclusion

Migrating to a modern version of SQL Server (meaning SQL Server 2016 or newer) is significantly more complicated than it was with legacy versions of SQL Server. Because of the changes associated with the various database compatibility levels and various cardinality estimator versions, it is actually very important to put some thought, planning, and actual testing into what database compatibility level you want to use on the new version of SQL Server that you are migrating your existing databases to.

Microsoft’s recommended upgrade process is to upgrade to the latest SQL Server version, but keep the source database compatibility level. Then, enable Query Store on each database and collect baseline data on the workload. Next, you set the database compatibility level to the latest version, and then use Query Store to fix your performance regressions by forcing the last known good plan.

You really want to avoid a haphazard “blind” migration where you are blissfully unaware of how this works and how your workload will react to these changes. Changing the database compatibility level to an appropriate version and using the appropriate database scoped configuration options, along with appropriate query hints where absolutely necessary, is extremely important with modern versions of SQL Server.

Another thing to consider (especially for ISVs) is that Microsoft is starting to really push the idea that you should think about testing and certifying your databases and applications to a particular database compatibility level rather than a particular version of SQL Server. Microsoft provides query plan shape protection when the new SQL Server version (target) runs on hardware that is comparable to the hardware where the previous SQL Server version (source) was running and the same supported database compatibility level is used both at the target SQL Server and source SQL Server.

The idea here is that once you have tested and certified your applications on a particular database compatibility level, such as 130, you will get the same behavior and performance if you move that database to a newer version of SQL Server (such as SQL Server 2017 or SQL Server 2019) as long as you are using the same database compatibility level and you are running on equivalent hardware.

The post The Importance of Database Compatibility Level in SQL Server appeared first on Glenn Berry.

Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds

Glenn Berry — Wed, 19 Dec 2018 22:21:48 +0000

As of July 29, 2019, there have been four Cumulative Updates (CU) for the Service Pack 3 branch of SQL Server 2014. There were a relatively large number of hotfixes in this last cumulative update. SP3 CU4 is the final Cumulative Update for SQL Server 2014 SP3, since SQL Server 2014 fell out of Mainstream Support on July 9, 2019.

If you are running on the SQL Server 2014 SP3 branch, I really think you should be running the latest SQL Server 2014 SP3 Cumulative Update.

Table 1 shows the SQL Server 2014 SP3 CU builds that have been released.

Build	Description	Release Date
12.0.6205	SP3 CU1	December 12, 2018
12.0.6214	SP3 CU2	February 19, 2019
12.0.6259	SP3 CU3	April 16, 2019
12.0.6329	SP3 CU4	July 29, 2019

Table 1: SQL Server 2014 SP3 CU Builds

You can follow the KB article link below to see all of the CU builds for the SQL Server 2014 RTM, SQL Server 2014 SP1, SQL Server 2014 SP2, and SQL Server 2014 SP3 branches.

SQL Server 2014 Build Versions

Like I have done for other versions and branches of SQL Server, I decided to scan the hotfix list for all of the Cumulative Updates in the SP3 branch, looking for performance and general reliability-related fixes for the SQL Server Database Engine. I came up with the list below, but this listing is completely arbitrary on my part. You may come up with a completely different list, based on what specific SQL Server 2014 features you are using.

Here are the fixes in the SP3 branch:

SQL Server 2014 SP3 Cumulative Update 1 (Build 12.0.6205), 13 total public hot fixes

FIX: Change Tracking cleanup message 22123 is unexpectedly recorded in the error log file in SQL Server

FIX: Incorrect results occur when you convert “pollinginterval” parameter from seconds to hours in sys.sp_cdc_scan in SQL Server

FIX: Access violation when you run a query that uses the XML data type in SQL Server 2014

FIX: Overestimations when using default Cardinality Estimator to query table with many null values

FIX: Access violation for query that uses INSERT INTO … SELECT to insert data into clustered columnstore index

FIX: “ran out of memory” error when executing a query on a table that has a large full-text index in SQL Server 2014 and 2016

FIX: I/O errors on a BPE file causes buffer time out in SQL Server

FIX: Assertion error occurs during restore of compressed backups in SQL Server 2016

FIX: Internal error messages when you update a FILESTREAM tombstone system table in SQL Server

FIX: ObjectPropertyEx does not return correct row count when there are partitions in a database object

FIX: SQL Server service crashes when DBCC CHECKDB runs against a database that has a corrupted partition in SQL Server

SQL Server 2014 SP3 Cumulative Update 2 (Build 12.0.6214), 5 total public hot fixes

FIX: High CPU use when large index is used in a query on a memory-optimized table in SQL Server

FIX: “Non-yielding” error occurs when there is a heavy use of prepared statements in SQL Server 2014 and 2016

FIX: Assertion occurs when a parallel query deletes from a Filestream table

SQL Server 2014 SP3 Cumulative Update 3 (Build 12.0.6259), 4 total public hot fixes

FIX: Query plans are different on clone database created by DBCC CLONEDATABASE and its original database in SQL Server 2016 and 2017

FIX: Columnstore filter pushdown may return wrong results when there is an overflow in filter expressions in SQL Server 2014

FIX: Log reader agent may fail after AG failover with TF 1448 enabled in SQL Server 2014

SQL Server 2014 SP3 Cumulative Update 4 (Build 12.0.6329), 19 total public hot fixes

FIX: Access violation occurs and server stops unexpectedly when you use XEvent session with sqlos.wait_info event in SQL Server

FIX: Filtered index may be corrupted when you rebuild index in parallel in SQL Server 2014 and 2016

FIX: Stack Dump occurs in the change tracking cleanup process in SQL Server 2014, 2016 and 2017

FIX: Fail to join the secondary replica if the database has a defunct filegroup in SQL Server 2014, 2016 and 2017

FIX: Columnstore filter pushdown may return wrong results when there is an overflow in filter expressions in SQL Server 2014, 2016 and 2017

FIX: Tlog grows quickly when you run auto cleanup procedure in SQL Server 2014, 2016 and 2017

FIX: SQL Server 2014 and 2016 do not perform the requested pre-row assignments when you use MERGE statement that performs assignments of local variables for each row

FIX: Prolonged non-transactional usage of FileTable without instance restart may cause non-yielding scheduler error or server hang in SQL Server 2014

FIX: Full-text search fails to remove files from \FTDATA\FilterData subfolder in SQL Server 2014

FIX: High CPU usage on Primary when SQL Service on Readable Secondary is turned off in Availability Group in SQL Server 2014

FIX: SQL batch performance drops when you enable “Force Encryption” in SQL Server 2014

FIX: Full text search auto populate stops when Availability Group goes offline in SQL Server 2014

FIX: Error 409 occurs when you back up databases by using BackuptoURL

FIX: Fix prefast warnings (62100) in Sql\Sqlrepl\xpreplclr.net\ReplCmdDataReader.cs to prevent SQL injection attacks

FIX: Syscommittab cleanup causes a lock escalation that will block the syscommittab flush in SQL Server 2014

The reason that I put these lists together is that I want to convince more people to try to keep their SQL Server instances up to date with Cumulative Updates. If you do the proper testing, planning and preparation, I think the risks from installing a SQL Server Cumulative Update are quite low (despite the occasional issues that people run into).

If you install a Cumulative Update or Service Pack on a Production system the day it is released, after doing no testing whatsoever, and then run into problems (and don’t have a plan on how to recover), then I don’t have that much sympathy for you.

On the other hand, if you go through a thoughtful and thorough testing process, and you have a plan for how you will install the CU, and how you would recover if there were any problems, then you are much less likely to have any problems. You are also much more likely to avoid the issues that are fixed by all of the included fixes in the new build of SQL Server. You have done your job as a good DBA.

Finally, Microsoft has changed their official guidance about whether you should install SQL Server Cumulative Updates. As they say, “we now recommend ongoing, proactive installation of CU’s as they become available”.

The post Performance and Stability Related Fixes in Post-SQL Server 2014 SP3 Builds appeared first on Glenn Berry.

SQL Server 2014 Service Pack 3 CU1 Released

Glenn Berry — Wed, 19 Dec 2018 22:04:05 +0000

On December 12, 2018, Microsoft released SQL Server 2014 Service Pack 3 CU1, which is Build 12.0.6205.1. There are 13 hotfixes in the public fix list. If you are running SQL Server 2014, you should be planning on getting on the SP3 branch as soon as possible (if you haven’t done it already). Keep in mind that SQL Server 2014 will fall out of Mainstream Support on July 9, 2019, which means there will be no more Service Packs or Cumulative Updates after that.

Microsoft also released SQL Server 2014 Service Pack 2 CU15 on the same day. It is Build 12.0.5605.1, and it has 7 hotfixes in the public fix list. If you are on the SP2 or an even earlier branch, you should be thinking about getting on SP3 as soon as you can.

The post SQL Server 2014 Service Pack 3 CU1 Released appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for December 2018

Glenn Berry — Fri, 14 Dec 2018 17:00:38 +0000

This month, I have just made some more minor improvements to most of the query sets, mainly in the comments and documentation.

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 1, SQL 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!

The post SQL Server Diagnostic Information Queries for December 2018 appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for November 2018

Glenn Berry — Sat, 03 Nov 2018 16:47:54 +0000

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

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.

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:

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

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

The post SQL Server Diagnostic Information Queries for November 2018 appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for October 2018

Glenn Berry — Wed, 24 Oct 2018 21:05:27 +0000

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

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.

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:

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

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

The post SQL Server Diagnostic Information Queries for October 2018 appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for September 2018

Glenn Berry — Tue, 25 Sep 2018 17:32:48 +0000

This month, I have added a separate set of queries for SQL Server 2019. I have also added two new queries to the SQL Server 2012 through SQL Server 2017 sets of queries.

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.

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:

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

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

The post SQL Server Diagnostic Information Queries for September 2018 appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for July 2018

Glenn Berry — Thu, 05 Jul 2018 22:18:46 +0000

This month, there are improvements to seven of the the SQL Server 2012 and newer versions of the queries, with a new column that shows whether there is a missing index warning in the cached query plan. A reader named Håkan Winther made this useful suggestion.

I have also developed 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 eight 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 2017, 2016 SP2, 2016, and 2014:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database 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:

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

If you want to understand how to better run and interpret these queries, you should consider listening to my three related Pluralsight courses, which are SQL Server 2014 DMV Diagnostic Queries – Part 1 , SQL Server 2014 DMV Diagnostic Queries – Part 2 and SQL Server 2014 DMV Diagnostic Queries – Part 3. All three of these courses are pretty short and to the point, at 67, 77, and 68 minutes respectively. Listening to these three 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!

The post SQL Server Diagnostic Information Queries for July 2018 appeared first on Glenn Berry.

SQL Server Diagnostic Information Queries for June 2018

Glenn Berry — Tue, 05 Jun 2018 21:50:56 +0000

This month, there are more minor updates to the SQL Server 2012 and newer versions of the queries, primarily in the comments and documentation. I have added some additional columns to many existing queries, and tried to get the newer versions uniformly updated and synchronized.

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.

Here are links to the latest versions of these queries for Azure SQL Database, SQL Server 2017, 2016 SP2, 2016, and 2014:

Azure SQL Database Diagnostic Information Queries

Azure SQL Database 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:

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

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

The post SQL Server Diagnostic Information Queries for June 2018 appeared first on Glenn Berry.

SQLskills SQL101: The Importance of Maintaining SQL Server

Glenn Berry — Mon, 14 May 2018 22:13:51 +0000

SQLskills has an ongoing initiative to blog about basic topics, which we’re calling SQL101. We’re all blogging about things that we often see done incorrectly, technologies used the wrong way, or where there are many misunderstandings that lead to serious problems. If you want to find all of our SQLskills SQL101 blog posts, check out SQLskills.com/help/SQL101.

When I look at many SQL Server instances in the wild, I still see a large percentage of instances that are running extremely old builds of SQL Server for whatever major of version of SQL Server is installed. This is despite years of cajoling and campaigning by myself and many others (such as Aaron Bertrand), and an official guidance change by Microsoft (where they now recommend ongoing, proactive installation of Service Packs and Cumulative Updates as they become available).

Microsoft has a helpful KB article for all versions of SQL Server that explains how to find and download the latest build of SQL Server for each major version:

Where to find information about the latest SQL Server builds

Here is my commentary on where you should try to be for each major recent version of SQL Server:

SQL Server 2017

SQL Server 2017 and newer will use the “Modern Servicing Model”, which does away with Service Packs. Instead, Microsoft will release Cumulative Updates (CU) using a new schedule of one every month for the first year after release, and then one every quarter for next four years after that.

Not only does Microsoft correct product defects in CUs, they also very frequently release new features and other product improvements in CUs. Given that, you should really try to be on the latest CU as soon as you are able to properly test and deploy it.

SQL Server 2017 Build Versions

Performance and Stability Fixes in SQL Server 2017 CU Builds

Reasons to Upgrade to SQL Server 2017

SQL Server 2016

SQL Server 2016 and older use the older “incremental servicing model”, where each new Service Pack is a new baseline (or branch) that has it’s own Cumulative Updates that are released every eight weeks. Microsoft corrects product defects in both Service Packs and in CUs, and they also very frequently release new features and other product improvements in both CUs and Service Packs.

As a special bonus, Microsoft has also gotten into the very welcome habit of actually backporting some features and improvements from newer versions of SQL Server into Service Packs for older versions of SQL Server. The latest example of this was SQL Server 2016 Service Pack 2 which has a number of improvements backported from SQL Server 2017.

SQL Server 2016 Build Versions

Performance and Stability Related Fixes in Post-SQL Server 2016 SP1 Builds

Performance and Stability Related Fixes in Post-SQL Server 2016 SP2 Builds

SQL Server 2016 Service Pack 2 Release Notes

SQL Server 2014

SQL Server 2014 will fall out of Mainstream Support from Microsoft on July 9, 2019. If you are running SQL Server 2014, you really should be on at least SQL Server 2014 SP2 (which got many improvements backported from SQL Server 2016), and ideally, you should be on the latest SP2 Cumulative Update. You should also be on the lookout for SQL Server 2014 SP3 which is due to be released sometime in 2018, which is very likely to have even more backported improvements.

If you are on SQL Server 2014 or SQL Server 2012, Microsoft has a very useful KB article that covers recommended updates and configuration options for high performance workloads. A number of these configuration options are already included if you are on the latest SP or newer for either SQL Server 2012 or SQL Server 2014.

SQL Server 2014 Build Versions

Performance and Stability Related Fixes in Post-SQL Server 2014 SP2 Builds

Hidden Performance and Manageability Improvements in SQL Server 2012/2014

SQL Server 2014 Service Pack 2 is now Available !!!

SQL Server 2012

SQL Server 2012 fell out of Mainstream Support from Microsoft on July 11, 2017. If you are running SQL Server 2012, you really should be on SQL Server 2012 SP4, ideally with the Spectre/Meltdown security update applied on top of SP4. Similar to SQL Server 2014 SP2, SQL Server 2014 SP4 also included a number of product improvements that were backported from SQL Server 2016.

SQL Server 2012 SP3 build versions

Performance and Stability Related Fixes in Post-SQL Server 2012 SP3 Builds

SQL Server 2012 Service Pack 4 (SP4) Released!

So just to recap, here are my recommendations by major version:

SQL Server 2017: Latest CU as soon as you can test and deploy

SQL Server 2016: Latest SP and CU as soon as you can test and deploy. Try to at least be on SQL Server 2016 SP2.

SQL Server 2014: Latest SP and CU as soon as you can test and deploy. Try to at least be on SQL Server 2014 SP2 (and SP3 when it is released).

SQL Server 2012: SP4 plus the security hotfix for Spectre/Meltdown.

The post SQLskills SQL101: The Importance of Maintaining SQL Server appeared first on Glenn Berry.