SQLskills SQL101: Using DDL Triggers

Over the past couple of months, SQLskills has embarked on a new initiative to blog about basic topics, which we’re calling SQL101. We’ll all be 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.

DDL Triggers

One very useful safety feature that was added to the product with the release of SQL Server 2005 is Data Definition Language (DDL) triggers. Even though they have been available for quite some time, I still don’t see that many people actually using them on their systems, which I think is a shame.

DDL triggers are described by the online documentation like this:

DDL triggers fire in response to a variety of Data Definition Language (DDL) events. These events primarily correspond to Transact-SQL statements that start with the keywords CREATE, ALTER, DROP, GRANT, DENY, REVOKE or UPDATE STATISTICS.

Basically, when a T-SQL command does something that affects the metadata or schema of your database, you can capture and log some useful information about what was changed, what the change was, when it was changed, and who did it. Depending on how you configure the DDL trigger, you can capture things that actually are metadata changes (such as CREATE, ALTER or DROP) for things like tables, views, stored procedures, functions, and indexes. You can also capture things that I don’t really consider true metadata changes, such as an ALTER INDEX REORGANIZE command.

DDL Trigger Actions

Just like with a DML Trigger, you have to decide what happens when a DDL Trigger fires. For example, one action that Microsoft likes to use in their documentation is to simply have a ROLLBACK command, along with an error message that indicates what happened. This is designed to prevent someone (perhaps you) from accidentally making a terrible mistake such as dropping a table from a Production database.

DDL Trigger Usage

Another common usage is to simply log relevant information about all DDL changes that you decide to capture to a table that you create in each database. This can be very useful when multiple people have admin rights in your Production databases. Even if that is not the case, having a record of all DDL changes to a database can be very helpful.

Another use for DDL Triggers is to capture what is happening with your index maintenance. DDL commands such as ALTER INDEX REORGANIZE and ALTER INDEX REBUILD can be logged to help you analyze your index maintenance. For example, if you see the same index being reorganized or rebuilt on a frequent, regular basis, you might want to consider lowering the fill factor on that index to reduce how quickly it becomes fragmented, which will decrease how often it needs to be reorganized or rebuilt.

Conclusion

DDL Triggers can be very useful, and they are very easy to use for a number of different purposes. They are not as secure or as powerful as SQL Server Audit, but they are available in all editions of SQL Server, starting with SQL Server 2005. They are also much easier to set-up and use. I have an example of how to create a table to log some DDL changes, along with an actual DDL trigger to capture the changes, available here.

 

 

SQL Server 2014 SP2 Cumulative Update 5

Microsoft has released SQL Server 2014 Service Pack 2 Cumulative Update 5, which is Build 12.0.5546.0. There are 24 hotfixes in the public fix list. In my opinion, you should be on the SP2 branch by now. If you have not made that move, you should be making plans to get on SP2 as soon as possible. My blog post below highlights some of the more important fixes in all of the post-SP2 Cumulative Updates:

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

Microsoft has also released SQL Server 2014 Service Pack 1 Cumulative Update 12, which is Build 12.0.4502.0. There are 12 hotfixes in the public fix list for this CU. My blog post below highlights some of the more important fixes in all of the post-SP1 Cumulative Updates:

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

There is no corresponding CU for the RTM branch, since SQL Server 2014 RTM is no longer a supported Service Pack level. If you are still on the RTM branch (which is not a good thing), then my blog post below highlights some of the more important fixes in all of the RTM Cumulative Updates:

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

Finally, if you are wondering why this matters, you might want to read my SQLskills SQL101: SQL Server Maintenance post to find out more about how SQL Server is serviced by Microsoft and why staying current is important.

 

 

SQLskills SQL101: Processor Selection for SQL Server

As Kimberly blogged about recently, SQLskills is embarking on a new initiative to blog about basic topics, which we’re calling SQL101. We’ll all be 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.

 

SQL Server Licensing

Since SQL Server 2012, Microsoft has been using core-based licensing for SQL Server Enterprise Edition. With non-virtualized servers, you are required to purchase a SQL Server core license for every single physical processor core in the entire host machine, period. Every single physical core present in the host machine must be licensed. It doesn’t matter if you have disabled physical cores in the host BIOS, or if you have exceeded the physical core license limit for SQL Server Standard Edition, you still have to license every single physical core in the machine.

With virtualization, the story is slightly different. Normally, you have to purchase a SQL Server core license for every single vCPU in your virtual machine, with a minimum of four core licenses per VM. The exception to this is if you purchase enough SQL Server core licenses for all of the physical cores in the entire host machine, and if you also purchase Microsoft Software Assurance. If you do this, you can then create as many VMs with as many vCPUs as you like, without worrying about counting the vCPU cores at all.

Windows Server 2016 Licensing

Windows Server 2016 has a new core-based licensing model with a minimum of eight physical core licenses per processor and 16 physical core licenses per host machine. Fortunately, these Windows Server 2016 core licenses are relatively affordable, especially for Windows Server 2016 Standard Edition (which is all that is required for most SQL Server 2016 instances). The danger from this new licensing model is that it may encourage well-meaning server administrators to select a processor with more physical cores than they actually need for SQL Server, in order to “get their money’s worth” from the Windows Server 2016 licenses that they are required to buy for a new server. This could actually be a very expensive mistake from a SQL Server 2016 licensing cost perspective!

Modern Server Processors for SQL Server

Current generation Intel server processors have anywhere from four to twenty-four physical cores in each physical processor. For two-socket servers, this means the Intel Xeon E5-2600 v4 “Broadwell-EP” Product Family. For four-socket and higher servers, this means the Intel Xeon E7-8800 v4 “Broadwell-EX” Product Family. Upcoming server processors from both AMD and Intel will have up to thirty-two physical cores per physical processor.

Previously, I explained the relevant differences between physical sockets, physical cores and logical cores here. One important fact to keep in mind is that Microsoft does not care (for pricing purposes) whether a physical core is fast or slow. Regardless of the performance of the core, the per-core license cost is exactly the same.

Knowing this, you should purposely choose a particular processor SKU that has the best single-threaded performance possible for a given physical core count. A very common mistake I see is where a server administrator purposely selects a low-range or mid-range processor SKU (at a given core count) to save a small amount of money on the hardware. Quite often, they save far less than 1% of the total system cost, but give up anywhere from 20-40% of their single-threaded performance.

For any particular server processor product family, you have a range of available processor SKUs with different physical core counts and other relevant performance specifications, such as base clock speed, L3 cache size, and QPI speed. Generally speaking, the lower core count processors have much better single-threaded CPU performance than the higher core count processors from the same product family. Quite often, you can purposely pick a fast, lower core count processor to both get better single-threaded CPU performance and to save a huge amount of money on your SQL Server 2016 licensing costs.

Conclusion

The key takeaway here is that it is very important to do some thoughtful analysis of your available processor choices for a server when you are going to have a SQL Server workload. The worst thing you can do is to just let someone else (who may not fully understand how SQL Server licensing works) make the choice with no input from you. It is unfortunately all too easy to make a very bad choice that costs significantly more than it should and also gives up a lot of performance.

I have written a number of articles for SQLPerformance.com that get into much more detail on this subject.

 

 

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

As of March 20, 2017, there have been two Cumulative Updates (CU) for the Service Pack 1 branch of SQL Server 2016. There have been a large number of hotfixes in each of these cumulative updates. If you are running on the SQL Server 2016 SP1 branch (which you should be by now), I really think you should be running the latest SQL Server 2016 SP1 Cumulative Update. Right now, that means SP1, CU2 (Build 13.0.4422.0), which was released on March 20, 2017. 

Table 1 shows the SQL Server 2016 SP1 CU builds that have been released so far.

BuildDescriptionRelease Date
13.0.4411SP1 CU1January 18, 2017
13.0.4422SP1 CU2March 20, 2017

Table 1: SQL Server 2016 SP1 CU Builds

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

SQL Server 2016 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 SP1 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 2016 features you are using.

Here are the fixes in the SP1 branch:

SQL Server 2016 SP1 Cumulative Update 1 (Build 13.0.4411), 54 total public hot fixes

FIX: The “sys.dm_db_column_store_row_group_physical_stats” query runs slowly on SQL Server 2016

FIX: DMV sys.dm_os_spinlock_stats returns incorrect results after you install SQL Server 2016 RTM CU2

FIX: SQL Server crashes when you execute a spatial data query that has been compiled in SQL Server 2016

FIX: An Always On secondary replica goes into a disconnecting state

FIX: A memory leak occurs when SQL Server procedure cache consumes too much memory

FIX: DMV sys.dm_hadr_availability_replica_states returns an incorrect synchronization health state for a distributed availability group

FIX: Out of memory occurs when you use long Hekaton transactions in SQL Server 2016

FIX: The Target Recovery Time of a database set to a nonzero value causes an assertion and a lease timeout in SQL Server 2014 or 2016

Decrease in performance and “non-yielding scheduler” errors caused by unnecessary spinlocks in SQL Server

FIX: Latch Contention may occur on execution of parallel queries on database that has Snapshot Isolation enabled in SQL Server 2016

FIX: Cannot execute the DBCC CLONEDATABASE command on an instance of SQL Server 2016 SP1 after an in-place upgrade

FIX: SQL Server crashes when you execute the OPENJSON function in a contained database in SQL Server 2016

FIX: SQL Server runs out of memory when you query data from memory-optimized tables if Resource Governor is enabled

FIX: Error messages are logged if database mirroring is configured by Transact-SQL in SQL Server 2016 and no database activity occurs for more than 90 seconds

Update to enable changing the PolyBase service accounts without reinstalling the PolyBase feature in SQL Server 2016

FIX: Error when create a stored procedure that uses a synonym together with an index hint in SQL Server 2016

FIX: An assert error occurs when you insert data into a memory-optimized table that contains a clustered columnstore index in SQL Server 2016

FIX: Error 3628 when you create or rebuild a columnstore index in SQL Server 2016

FIX: An access violation occurs when you execute DBCC CHECKDB on a database in SQL Server 2016

FIX: A dump file is generated when you enable system-versioning on a table in SQL Server 2016

FIX: Kernel crash when you create a database after you drop a database that contains FILESTEAM data in SQL Server 2016

FIX: An assertion occurs when you bulk insert data into a table from multiple connections in SQL Server 2016

An error occurs when you use ODBC driver to retrieve sql_variant data in SQL Server 2014 or 2016

FIX: Automatic update of statistics feature doesn’t run after you truncate a table that has a clustered columnstore index

FIX: A query that contains a hint against a view that references at least one temporal table in a different database can generate a dump file in SQL Server 2016

 

SQL Server 2016 SP1 Cumulative Update 2 (Build 13.0.4422), 101 total public hot fixes

FIX: The change table is ordered incorrectly for updated rows after you enable change data capture for a Microsoft SQL Server database

FIX: Memory leak when you query sys.dm_sql_referenced_entities view in SQL Server 2014 or 2016

FIX: Changing the data type and then updating the table with more than 4,000 records causes database corruption

FIX: Cannot insert data into a table that uses a clustered columnstore index in SQL Server 2016

FIX: Incremental statistics runs with higher sample rate than regular statistics when statistics are created or updated in SQL Server 2014 or 2016

FIX: DMV sys.dm_hadr_availability_replica_states returns an incorrect synchronization health state for a distributed availability group

FIX: ALTER TABLE, ADD CONSTRAINT, and PRIMARY KEY statements do not detect a duplicate key in SQL Server 2016

FIX: Cannot install SQL Server R Services during an offline installation of SQL Server 2016 updates

Improvement: Enhance VDI Protocol with VDC_Complete command in SQL Server

FIX: Unable to rebuild the partition online for a table that contains a computed partitioning column in SQL Server 2016

FIX: Assertion error when dm_exec_query_statistics_xml is used in a query plan that contains certain operators in SQL Server 2016

FIX: Wrong number of rows returned in sys.partitions for Columnstore index in SQL Server 2016

Statistics are removed after rebuilding a specific partition of an partitioned aligned index on a partitioned table in SQL Server

FIX: On failover, the new secondary replica stops accepting transaction log records until the instance is restarted in SQL Server

FIX: Deadlock when you execute a query plan with a nested loop join in batch mode in SQL Server 2014 or 2016

FIX: SQL Server crashes when you execute a spatial data query that has been compiled in SQL Server 2016

FIX: An assert error occurs when you insert data into a memory-optimized table that contains a clustered columnstore index in SQL Server 2016

FIX: DBCC CLONEDATABASE doesn’t copy the runtime cache of the query store to the clone in SQL Server 2016 SP1

FIX: Distribution Agent fails for a SQL Server 2014 publisher and a SQL Server 2012 subscriber in Transactional Replication

FIX: Incorrect full-text keys are recorded for the rows that aren’t indexed correctly by a full-text index in SQL Server

FIX: Data type conversion error in a query that involves a column store index in SQL Server 2016

FIX: Error 2809 when you execute a stored procedure that takes a table-valued parameter from RPC calls in SQL Server 2014 or 2016

FIX: Deadlock causes deferred transaction on the secondary replica in an Always On environment

FIX: “Non-yielding Scheduler” condition when you parallel-load data into a columnstore index in SQL Server 2016

SQL Server crashes with an access violation when you use the TRY…CATCH construct for bulk copy

FIX: Rebuilding a nonclustered index to add columns by using CREATE INDEX with DROP_EXISTING=ON and ONLINE=ON causes blocking

FIX: DBCC CHECKFILEGROUP reports false inconsistency error 5283 on a database that contains a partitioned table in SQL Server

Update improves DMV sys.dm_server_services and sys.dm_os_sys_info in SQL Server 2016

FIX: A memory leak occurs when SQL Server procedure cache consumes too much memory

FIX: “Incorrect syntax for definition of the ‘default’ constraint” error when you add an arbitrary columnstore column in SQL Server 2016

FIX: Error when you add a NOT NULL column with default values to a non-empty clustered columnstore index in SQL Server 2016 Standard and Express edition

FIX: Memory leak when you run a query that you don’t have sufficient permissions for in SQL Server 2014 or 2016

FIX: Intra-query deadlock when values are inserted into a partitioned clustered columnstore index in SQL Server 2014 or 2016

FIX: Assert memory dump on a mirror server in SQL Server

FIX: Error 5262 when you execute DBCC CHECKDB on the primary replica in SQL Server 2012, 2014 or 2016

FIX: Availability databases in incorrect initializing/synchronizing state after failover of SQL Server 2014 or 2016 AlwaysOn availability group

FIX: More CPU consumption when many consecutive transactions insert data into a temp table in SQL Server 2016 than in SQL Server 2014

FIX: CREATE OR ALTER statement applied on a DDL trigger fails on the next execution in SQL Server 2016

Improvement: Enable SQL Server Managed Backup to back up databases that are larger than 50 GB to Microsoft Azure in SQL Server 2016

Improvement: Improves the query performance for SQL Server 2016 by changing the use of histograms on UNIQUE columns

FIX: The sys.column_store_segments catalog view displays incorrect values in the column_id column in SQL Server 2016

FIX: Memory is paged out when columnstore index query consumes lots of memory in SQL Server 2014 or 2016

FIX: An access violation occurs when you execute DBCC CHECKDB on a database in SQL Server 2016

FIX: Error 21050 when you remove a table that is not part of a publication in SQL Server 2014 or 2016

FIX: Queries that run against secondary databases always get recompiled in SQL Server

FIX: Out-of-memory errors when you execute DBCC CHECKDB on database that contains columnstore indexes in SQL Server 2014 or 2016

FIX: Error 3628 when you create or rebuild a columnstore index in SQL Server 2016

FIX: Significantly increased PAGELATCH_EX contentions in sys.sysobjvalues in SQL Server 2016

FIX: Incorrect query result when you use varchar(max) variable in the search condition in SQL Server 2014 or 2016

FIX: You cannot select any replica when you fail over from an availability group that’s in the resolving state

FIX: No automatic failover after database mirroring stops unexpectedly in SQL Server

FIX: TDE encrypted Databases go in suspect state during the recovery phase when you restart SQL Server

FIX: Bad query plan created on secondary replicas after FULLSCAN statistics update on primary replica in SQL Server 2016

FIX: Checkpoint files grow excessively when you insert data into memory-optimized tables in SQL Server 2016

 

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”.

SQL Server Diagnostic Information Queries for April 2017

This month, there are more minor updates for several of the SQL Server 2012 and newer version queries. There is also a new query that looks at the suspect pages table in msdb.

Rather than having a separate blog post for each version, I have just put the links for all seven 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 SQL Server 2017, 2016, 2014 and 2012:

SQL Server 2017 Diagnostic Information Queries

SQL Server 2017 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

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

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

Since SQL Server 2008 R2 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. I did update these queries slightly in January 2017 though.

SQL Server 2008 R2 Diagnostic Information Queries (CY 2017)

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries (CY 2017)

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries (CY 2017)

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 three related Pluralsight courses, which are 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 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!

SQL Server 2016 Service Pack 1 CU2 Released

On March 20, 2017, Microsoft released SQL Server 2016 Service Pack 1 CU2, which is Build 13.0.4422.0. This CU has 101 fixes in the public fix list, by my count. This is a pretty large CU, and if you look at the fix list in more detail, many of them are for pretty significant issues with AGs, columnstore indexes, and general performance.

Here are many of the more interesting Engine fixes:

FIX: Incremental statistics runs with higher sample rate than regular statistics when statistics are created or updated in SQL Server 2014 or 2016

Statistics are removed after rebuilding a specific partition of an partitioned aligned index on a partitioned table in SQL Server

FIX: On failover, the new secondary replica stops accepting transaction log records until the instance is restarted in SQL Server

FIX: Deadlock when you execute a query plan with a nested loop join in batch mode in SQL Server 2014 or 2016

FIX: “Non-yielding Scheduler” condition when you parallel-load data into a columnstore index in SQL Server 2016

FIX: DBCC CHECKFILEGROUP reports false inconsistency error 5283 on a database that contains a partitioned table in SQL Server

FIX: A memory leak occurs when SQL Server procedure cache consumes too much memory

FIX: Assert memory dump on a mirror server in SQL Server

FIX: Error 5262 when you execute DBCC CHECKDB on the primary replica in SQL Server 2012, 2014 or 2016

FIX: Availability databases in incorrect initializing/synchronizing state after failover of SQL Server 2014 or 2016 AlwaysOn availability group

FIX: More CPU consumption when many consecutive transactions insert data into a temp table in SQL Server 2016 than in SQL Server 2014

Improvement: Improves the query performance for SQL Server 2016 by changing the use of histograms on UNIQUE columns

FIX: Memory is paged out when columnstore index query consumes lots of memory in SQL Server 2014 or 2016

FIX: Queries that run against secondary databases always get recompiled in SQL Server

FIX: Out-of-memory errors when you execute DBCC CHECKDB on database that contains columnstore indexes in SQL Server 2014 or 2016

FIX: Significantly increased PAGELATCH_EX contentions in sys.sysobjvalues in SQL Server 2016

FIX: No automatic failover after database mirroring stops unexpectedly in SQL Server

FIX: TDE encrypted Databases go in suspect state during the recovery phase when you restart SQL Server

 

If you are running SQL Server 2016, you should be on the Service Pack 1 branch as soon as possible. If you are on the SP1 branch, then you should make an effort to be on the latest Cumulative Update as soon as you are able to complete the planning, testing and deployment process. Nearly a year ago, Microsoft changed their guidance about deploying CUs. Since then, Microsoft recommends ongoing, proactive installation of CUs as they become available.

 

 

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

As of April 17, 2017, there have been five Cumulative Updates (CU) for the Service Pack 2 branch of SQL Server 2014. There have been a large number of hotfixes in each of these cumulative updates. If you are running on the SQL Server 2014 SP2 branch, I really think you should be running the latest SQL Server 2014 SP2 Cumulative Update. Right now, that means SP2, CU5 (Build 12.0.5546), which was released on February 21, 2017.

Table 1 shows the SQL Server 2014 SP2 CU builds that have been released so far.

BuildDescriptionRelease Date
12.0.5511SP2 CU1August 25, 2016
12.0.5522SP2 CU2October 17, 2016
12.0.5538SP2 CU3December 19, 2016
12.0.5540SP2 CU4February 21, 2017
12.0.5546SP2 CU5April 17, 2017
   

Table 1: SQL Server 2014 SP2 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, and SQL Server 2014 SP2 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 SP2 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 SP2 branch:

SQL Server 2014 SP2 Cumulative Update 1 (Build 12.0.5511), 39 total public hot fixes

FIX: SQL Server crashes when you run a remote query in a stored procedure by using an invalid user name

FIX: Incorrect results when you use a LIKE operator and an “ss” wildcard in SQL Server 2014 or 2016

FIX: Memory leak on the AlwaysOn secondary replica when change tracking is enabled in SQL Server

“The log backup chain is broken” error when the log backup process fails in SQL Server

FIX: Error 1478 when you add a database back to the AlwaysOn availability group in SQL Server

Transaction log backup failure on the secondary replica prevents subsequent backups on Availability Replicas in SQL Server

FIX: Service Broker UCS task leaks memory in SQL Server 2014

Decrease in performance and “non-yielding scheduler” errors caused by unnecessary spinlocks in SQL Server

Operating system error 32 when you restore a database in SQL Server 2014

 

SQL Server 2014 SP2 Cumulative Update 2 (Build 12.0.5522), 17 total public hot fixes

Improved SQL Server stability and concurrent query execution for some columnstore queries in SQL Server 2014 and 2016

SQL Server 2012 crashes with an access violation when you use the TRY…CATCH construct for bulk copy

FIX: Queries that use CHANGETABLE use much more CPU after you install SQL Server 2014 SP1 CU6

FIX: A deadlock occurs when you execute a query plan that has a nested loop join between two hash joins working in the batch mode in SQL Server 2014

FIX: Cannot uninstall service packs for SQL Server 2014 after a cumulative update is installed

A memory leak occurs when you use Azure Storage in SQL Server 2014 or 2016

FIX: Access violation when you run a query that uses clustered columnstore index with trace flag 2389, 2390, or 4139

 

SQL Server 2014 SP2 Cumulative Update 3 (Build 12.0.5538), 37 total public hot fixes

FIX: Deadlock causes deferred transaction on the secondary replica in an Always On environment

A memory leak occurs when you use Azure Storage in SQL Server 2014 or 2016

Unexpected growth of tempdb data files when using SQL Server Service Broker

FIX: TDE encrypted Databases go in suspect state during the recovery phase when you restart SQL Server 2012 or 2014

FIX: On failover, the new secondary replica stops accepting transaction log records until the instance is restarted in SQL Server

FIX: An assertion occurs when you restore a clone database that has Query Store enabled in SQL Server 2014

FIX: DBCC CHECKFILEGROUP reports false inconsistency error 5283 on a database that contains a partitioned table in SQL Server

FIX: Availability databases in incorrect initializing/synchronizing state after failover of SQL Server 2014 AlwaysOn availability group

Statistics are removed after rebuilding a specific partition of an partitioned aligned index on a partitioned table in SQL Server

Updates to DBCC CLONEDATABASE functionality in SQL Server 2014

FIX: You cannot select any replica when you fail over from an availability group that’s in the resolving state

FIX: Out-of-memory errors when you execute DBCC CHECKDB on database that contains columnstore indexes in SQL Server 2014

FIX: Rebuilding a nonclustered index to add columns by using CREATE INDEX with DROP_EXISTING=ON and ONLINE=ON causes blocking

FIX: Queries that run against secondary databases always get recompiled in SQL Server

FIX: Distribution Agent fails for a SQL Server 2014 publisher and a SQL Server 2012 subscriber in Transactional Replication

FIX: The Target Recovery Time of a database set to a nonzero value causes an assertion and a lease timeout in SQL Server 2014

FIX: No automatic failover after database mirroring stops unexpectedly in SQL Server 2012 or 2014

FIX: Intra-query deadlock when values are inserted into a partitioned clustered columnstore index in SQL Server 2014

 

SQL Server 2014 SP2 Cumulative Update 4 (Build 12.0.5540), 25 total public hot fixes

FIX: Error 2809 when you execute a stored procedure that takes a table-valued parameter from RPC calls in SQL Server 2014

FIX: Memory is paged out when columnstore index query consumes lots of memory in SQL Server 2014

FIX: A system assert occurs when a Transact-SQL stored procedure with a TVP argument is called from a SQLCLR procedure

FIX: Access Violation when you execute queries on a readable secondary replica of a SQL Server 2014 AlwaysOn Availability Group

FIX: Error 5262 when you execute DBCC CHECKDB on the primary replica that contains repaired data pages in SQL Server 2012 or 2014

FIX: An Always On secondary replica goes into a disconnecting state

FIX: Cannot connect to a named instance after failover on a mirror server in SQL Server 2016 or 2014

FIX: Fails to execute the DBCC CLONEDATABASE command on an in-place upgrade instance of SQL Server

FIX: Incremental statistics runs with higher sample rate than regular statistics when statistics are created or updated in SQL Server 2014

FIX: Incorrect query result when you use varchar(max) variable in the search condition in SQL Server 2014

FIX: Changing the data type and then updating the table with more than 4,000 records causes database corruption

FIX: Memory leak occurs when you run a query that you don’t have enough permissions in SQL Server 2014

FIX: SQL Server is stopped when you install patches on an instance of SQL Server 2014 that contains many databases

 

SQL Server 2014 SP2 Cumulative Update 5 (Build 12.0.5546), 24 total public hot fixes

FIX: Access violation in SQL Server 2014 when large number of rows are inserted into a partitioned columnstore index

FIX: Service Broker endpoint connections aren’t closed after an availability group failover in SQL Server

FIX: Bad query plan created on secondary replicas after statistics updated via FULLSCAN option on primary replica in SQL Server 2012 or 2014

Update improves handling of documents too large for Full-Text Search indexing in SQL Server

FIX: DMV sys.dm_hadr_availability_group_states displays “NOT_HEALTHY” in synchronization_health_desc column on secondary replicas in SQL Server 2012 or 2014

FIX: Failed assertion and many access violation dump files after the sp_replcmds stored procedure is canceled in SQL Server 2012 or 2014

FIX: Many HkHostLogCheckpointRecord() messages are logged in the SQL Server error log

FIX: A memory leak in SQLWEP causes the host process Wmiprvse.exe to crash in SQL Server 2012 or 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”.

SQL Server Diagnostic Information Queries for March 2017

This month, there are minor updates for the SQL Server 2012 and newer version queries.

Rather than having a separate blog post for each version, I have just put the links for all seven 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 SQL Server vNext, 2016, 2014 and 2012:

SQL Server vNext Diagnostic Information Queries

SQL Server nNext 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

SQL Server 2012 Diagnostic Information Queries

SQL Server 2012 Blank Results Spreadsheet

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

Since SQL Server 2008 R2 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. I did update these queries slightly in January 2017 though.

SQL Server 2008 R2 Diagnostic Information Queries (CY 2017)

SQL Server 2008 R2 Blank Results Spreadsheet

SQL Server 2008 Diagnostic Information Queries (CY 2017)

SQL Server 2008 Blank Results Spreadsheet

SQL Server 2005 Diagnostic Information Queries (CY 2017)

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 three related Pluralsight courses, which are 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 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!

SQLskills SQL101: SQL Server Maintenance

Microsoft has a methodology for developing and distributing updates to SQL Server, which they call the Incremental Servicing Model (ISM).  This model has a hierarchy of on-demand hotfixes (HFs), Cumulative Updates (CUs), and Service Packs (SPs) that are used to distribute updates to SQL Server. 

Microsoft’s official policy and guidance about when and whether to apply SQL Server updates changed on March 24, 2016, as described here. It is important that DBAs understand how this update system works whether they are working with traditional on-premises SQL Server or SQL Server running in an Azure VM (or any other IaaS cloud solution such as Amazon EC2).

Why do you need to maintain SQL Server?

Actively maintaining your SQL Server instances by proactively installing CUs and SPs as they become available will make your database server more reliable and possibly perform better. Microsoft has historical CSS data that indicates that a significant percentage of customer issues have already been fixed in a previously released CU, that had not been applied by the customer. My own personal experience as a DBA and consultant reinforces this view.

What happens if I don’t maintain my SQL Server instances?

You are more likely to run into problems that Microsoft has already fixed (because other customers have run into them). If your build of SQL Server is old enough, it may actually become what is called an “unsupported service pack”, which means that Microsoft CSS may be unwilling to fully support you (beyond basic troubleshooting) until you update to a supported service pack level. You don’t want to find yourself in this situation!

Are there any other benefits from updating SQL Server?

Developing a detailed plan for how you test and deploy a SQL Server update, and then actually implementing and updating the plan on a regular basis forces you and your organization to have a plan you also can follow whenever you make any kind of change or update to your database servers or the applications that use them. If you have any sort of HA/DR technology in place, updating SQL Server gives you an opportunity to use it in a planned fashion to minimize your downtime. Doing this on a regular basis validates your HA/DR solution and increases your confidence that it actually works as designed.

Are there any risks from updating SQL Server?

Certainly. Anytime you make any change to a computer system, there is a chance that something can go wrong. That is why you should have a written plan for how you test and deploy a SQL Server update that also includes how to rollback and recover in case something does go wrong. In reality, it is actually quite rare for a SQL Server update to cause a problem, but that doesn’t mean you should not be ready to deal with it if it does happen. Having a detailed plan that you actually follow dramatically decreases the chances of having any issues when you deploy your SQL Server update to Production.

How often does Microsoft release Cumulative Updates?

Microsoft releases Cumulative Updates every eight weeks for the versions of SQL Server that are still in mainstream support. This includes SQL Server 2012, SQL Server 2014, and SQL Server 2016. Currently, the CU release cycles for SQL Server 2012 and SQL Server 2016 are in sync, while SQL Server 2014 releases CUs slightly later. Hopefully, they will get the CU release cycle for all three versions back in sync.

How do I find out about new SQL Server Cumulative Updates?

The first place to look is the SQL Server Release Services blog. You can also check these Microsoft KB articles:

How do I find more information about this subject?

You can watch my Pluralsight courses SQL Server 2012: Installation and Configuration and SQL Server: Installing and Configuring SQL Server 2016, and read my article on SQLPerformance.com, Making the Case for Regular SQL Server Servicing.

You can attend one of our in-person training classes, such as IE0: Immersion Event for the Accidental/Junior DBA or IEHADR: Immersion Event on High Availability and Disaster Recovery. You can also contact me if you have specific questions. And, if you want to find all of our SQLskills SQL101 blog posts – check out: SQLskills.com/help/SQL101

Thanks for reading!

SQL Server 2014 Service Pack 2 Cumulative Update 4

Microsoft has released SQL Server 2014 Service Pack 2 Cumulative Update 4, which is Build 12.0.5540.0. There are 30 hotfixes in the public fix list. In my opinion, you should be on the SP2 branch by now. If you have not made that move, you should be making plans to get on SP2 as soon as possible.

They have also released SQL Server 2014 Service Pack 1 Cumulative Update 11, which is Build 12.0.4502.0. There are 15 hotfixes in the public fix list for this CU.

There is no corresponding CU for the RTM branch, since SQL Server 2014 RTM is no longer a supported Service Pack level.