SQL Server 2016 SP2 CU8: What You Need to Know

SQL Server 2016 SP2 Cumulative Update 8 is a mandatory patch for any organisation still running SQL Server 2016 SP2. Released by Microsoft in July 2019, this update addresses 13 significant bugs spanning backup and recovery, replication, high availability, security, and Analysis Services. If you're managing a SQL Server 2016 environment, this isn't optional.

Earlier that same month, Microsoft pushed an out-of-band security patch for SQL Server 2016. Some DBAs assumed that covered their patching obligations for the month. It didn't. SP2 CU8 arrived shortly after and contained critical fixes that the security patch didn't touch. Running both is necessary.

Why Does SP2 CU8 Matter for SQL Server 2016?

Cumulative updates aren't just about ticking a compliance box. Several of the bugs fixed in SQL Server 2016 SP2 CU8 have real operational consequences, including outages, data integrity risks, and silent failures in security features. When a bug can cause your transaction log to fill up and take down a production system, or silently skip encrypting your data, you're dealing with risks that no DBA should accept.

Let's go through the most significant fixes in this update and explain what was actually broken.

What Bugs Were Fixed in SQL Server 2016 SP2 CU8?

Compressed Encrypted Backup Restore Failures

Restoring a compressed, encrypted backup was failing in certain scenarios. This is a particularly nasty bug because it strikes at the moment you most need your backups to work. Discovering your restore process is broken during a disaster recovery event is not the time to find out your backups aren't viable. This fix should be verified with a post-update restore test.

Dynamic Data Masking Not Working as Expected

Dynamic Data Masking is a feature organisations use to restrict sensitive data exposure to non-privileged users. When masking doesn't behave correctly, data that should be obscured gets exposed. For environments handling personally identifiable information or subject to privacy regulations, this is a compliance issue, not just a technical inconvenience.

DAX Queries Consuming 200x the Database Size in Memory

This one is significant for anyone running SQL Server Analysis Services alongside their relational workloads. Certain DAX queries were consuming memory at roughly 200 times the size of the database being queried. On a modest SSAS database, that's manageable. On a large one, it means memory exhaustion and query failures. The fix brings memory consumption back to reasonable levels.

Peer-to-Peer Replication Fails When Hostname Is Not Uppercase

This is the kind of bug that causes hours of head-scratching. Peer-to-peer transactional replication was failing silently when the server hostname was not in uppercase. It's the sort of environment-specific issue that might work fine in your test environment and break in production depending on how your servers were named. The fix removes this case-sensitivity dependency.

Query Store Cleanup Filling the Transaction Log

This is arguably the most operationally dangerous bug in the list. Query Store cleanup operations were generating excessive transaction log activity, to the point where the log could fill completely and cause a production outage. Query Store is enabled by default in many environments and is often left running without close monitoring of its internal maintenance behaviour. If you're running SP2 without CU8, check your transaction log growth trends.

Distributed Availability Groups Causing Memory Dumps During Automatic Seeding

Automatic seeding in Distributed Availability Groups was triggering memory dumps. Memory dumps degrade performance and, depending on your configuration, can cause SQL Server to restart. In a high-availability setup, that's exactly the kind of instability you're trying to avoid.

Availability Group Replication Stopping Due to Internal Thread Deadlocks

AG replication was stopping due to internal thread deadlocks within SQL Server itself. This isn't a deadlock between user queries. It's a deadlock inside the replication threads, which means standard deadlock troubleshooting tools won't surface it easily. The symptom is replication simply stopping. The fix resolves the internal threading issue.

Deadlock Monitor Causing Access Violations

The deadlock monitor, which is the component responsible for detecting and resolving deadlocks, was itself capable of causing an access violation. An access violation in SQL Server typically results in a process crash or memory dump. Having your safety net cause the problem it's meant to prevent is a significant issue.

Querying a View with UNION on a Linked Server

Querying a view that contained a UNION clause through a linked server was causing errors. Linked server queries are already a performance concern in most environments, and adding instability on top of that makes them even harder to rely on. This fix restores expected behaviour for that specific query pattern.

Concurrent Inserts into Clustered Columnstore Indexes Causing Deadlocks

Columnstore indexes are commonly used in reporting and analytics workloads where multiple processes might be inserting data simultaneously. Concurrent inserts were causing deadlocks, which means failed transactions and retry overhead. For high-throughput data loading scenarios, this fix has a direct impact on reliability.

Infinite Loop When FileTable Is Used Without a Server Restart

FileTable, which allows SQL Server to store and manage files through the file system, was entering an infinite loop condition in long-running environments that hadn't been restarted recently. This is the kind of bug that only surfaces over time and can be difficult to diagnose without knowing it exists.

SSAS 2016 Random Crashes

SQL Server Analysis Services 2016 was crashing unpredictably. Random crashes in a reporting platform mean unavailability for end users and potential data inconsistency in cached results. The fix addresses the underlying cause of these crashes.

Transparent Data Encryption Skipping Encryption After a Restart Mid-Process

This is a serious security bug. If TDE encryption was in progress and SQL Server was restarted before it completed, the encryption process would not resume correctly. Data that should have been encrypted remained unencrypted, with no obvious indication that the encryption had not completed. For any organisation relying on TDE for data-at-rest encryption, this is a critical fix.

How Do You Apply SQL Server 2016 SP2 CU8?

Applying the update follows the standard cumulative update process:

  1. Download the update package from the Microsoft support page for SQL Server 2016 SP2 CU8.
  2. Back up all databases, including system databases, before proceeding.
  3. Apply the update to a non-production environment first and validate application behaviour.
  4. Schedule a maintenance window for production. Most CU installs require a SQL Server service restart.
  5. After the update, run a restore test to verify backup and recovery is functioning correctly, particularly given the compressed encrypted backup fix in this release.
  6. Monitor transaction log usage for the first few days post-update to confirm the Query Store cleanup issue is resolved.

A Note on SQL Server 2016 End of Life

SQL Server 2016 reached mainstream end of support in July 2021 and moves to end of extended support in July 2026. If you're still running SQL Server 2016, staying current on cumulative updates is essential because Microsoft won't backport fixes to older CU levels. Running an unpatched SQL Server 2016 instance means carrying known, documented bugs with no remediation path other than applying the update yourself.

Planning your upgrade path to SQL Server 2019 or SQL Server 2022 should be on your roadmap now, not when extended support ends.

Key Takeaways

  • SQL Server 2016 SP2 CU8 fixes 13 significant bugs, including a TDE encryption failure, a Query Store cleanup issue that can cause outages, and a peer-to-peer replication failure tied to hostname casing.
  • The July 2019 security patch for SQL Server 2016 does not replace SP2 CU8. Both are required.
  • The Query Store transaction log bug and the TDE mid-restart bug are the two highest-risk issues in this release and should be treated as urgent reasons to patch.
  • After applying the update, run a restore test and monitor transaction log growth to confirm the fixes are working as expected.
  • SQL Server 2016 extended support ends July 2026. If you're still on this version, now is the time to start planning your upgrade.

If you're managing SQL Server 2016 environments and want confidence that your patching, configuration, and monitoring are all in order, DBA Services offers SQL Server health checks and managed support for organisations across Australia. We can assess your current patch level, identify configuration risks, and help you build a practical upgrade roadmap. Get in touch to find out more.