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