SQL Server 2016 SP2 Cumulative Update 9: Why You Should Wait for CU10

Do not install SQL Server 2016 SP2 Cumulative Update 9. Microsoft has confirmed an uninstall issue with this release. If you haven't already applied CU9, hold off and wait for the expedited CU10 release that Microsoft has committed to shipping. This is one of those rare situations where the right patching advice is to pause rather than proceed.

That said, understanding what CU9 contains is still worthwhile. CU10 will carry the same fixes forward, and knowing what's being addressed helps you prioritise the patch window and communicate the value of the update to stakeholders.

What Is the Problem with SQL Server 2016 SP2 CU9?

The issue isn't with the fixes inside CU9. Microsoft has confirmed the payload itself is fine and the bug fixes work as intended. The problem is with the uninstall mechanism. If you apply CU9 and later need to roll it back, you'll hit a failure in the uninstall process.

For most production environments, that's an unacceptable risk. Patching discipline isn't just about applying updates, it's about maintaining a reliable rollback path. If something goes wrong after a patch and you can't cleanly uninstall, you're in a difficult position. Microsoft recognised this quickly and flagged the issue in the updated KB article, recommending customers wait for CU10.

The updated guidance from Microsoft states:

"There is an uninstall issue with SQL16 SP2 CU9. The payload in CU9 is fine, but if you have not already installed CU9, it is recommended that you wait for the upcoming expedited SQL16 SP2 CU10 release."

If you have already installed CU9, the advice is different. Your instance is running the fixes correctly. The uninstall issue only becomes relevant if you need to roll back, so monitor your environment closely and plan to move to CU10 when it drops.

What Fixes Are Included in SQL Server 2016 SP2 CU9?

Even though we're recommending you wait, it's worth understanding the fixes included in this cumulative update. These will carry through into CU10, and several of them address bugs that affect common production workloads.

Transaction log not truncating in a single-node Availability Group

This is a significant one. In certain configurations involving a single-node AG, the transaction log was not being truncated as expected. Left unchecked, this causes log files to grow unbounded, which can fill disk volumes and bring down a production instance. If you've been seeing unexplained log growth on a single-node AG, this fix is directly relevant to your environment.

Access violation with PIVOT and UNPIVOT operations

An access violation could be triggered when executing queries using PIVOT or UNPIVOT. Access violations in SQL Server are serious, as they typically result in a process termination or, in some cases, a service restart. Queries using these operators on affected builds needed to be treated with caution.

Incorrect results with partitioned clustered columnstore indexes

Columnstore indexes are widely used for analytical workloads and reporting queries. Getting incorrect results from a query is arguably worse than getting an error, because you may not immediately realise the data is wrong. This fix addresses a specific scenario involving partitioned clustered columnstore indexes returning bad data.

Access violation when restoring an In-Memory OLTP database

In-Memory OLTP (formerly known as Hekaton) is used in high-throughput transactional environments. An access violation during a restore operation is a serious bug, particularly if you're testing disaster recovery procedures or performing a database migration. This fix resolves that instability.

Frozen I/O not resuming after backup with In-Memory OLTP

During a backup of a database containing In-Memory OLTP tables, I/O could become frozen and fail to resume. This has obvious implications for backup reliability and overall instance health. Backup operations need to complete cleanly and consistently, and this bug undermined that.

Availability Groups direct seeding stopping unexpectedly

Direct seeding is the mechanism that allows AG replicas to be initialised without manually restoring a backup. If direct seeding stops and fails to resume, setting up or recovering an AG replica becomes a manual, time-consuming process. This fix allows direct seeding to stop and start as expected.

sys.database_scoped_configurations returning incorrect results

This fix has a practical impact for anyone using sp_Blitz or similar diagnostic tools. The sp_Blitz check for non-default database scoped configurations queries sys.database_scoped_configurations, and the bug was causing that check to return incorrect results. With this fix in place, the check works as intended and you can trust the output.

Improved cardinality estimation

Cardinality estimation is the process SQL Server uses to estimate how many rows a query will return at each step of the execution plan. Poor cardinality estimates lead to suboptimal plans, which means slower queries. Improvements in this area can have a meaningful impact on query performance across a range of workloads, particularly for complex queries involving joins and filters on large tables.

Should You Apply This Update If You've Already Installed CU9?

If CU9 is already running in your environment, don't panic. Your instance is benefiting from all the fixes listed above, and the uninstall issue won't affect you unless you actively try to roll back. The recommended approach is:

  1. Monitor your environment for any unexpected behaviour.
  2. Plan to apply CU10 as soon as it becomes available.
  3. Test CU10 in a non-production environment before rolling it out to production.
  4. Document the CU9 installation in your change management records so the patching history is clear.

Do not attempt to uninstall CU9 unless you have a specific technical reason to do so and have engaged Microsoft support.

What's the Right Patching Cadence for SQL Server 2016?

SQL Server 2016 is a mature release, but it still sees active cumulative update development. Microsoft typically ships cumulative updates on a roughly 60-day cycle, which means you can expect CU10 to follow CU9 relatively quickly given the expedited release commitment.

The general recommendation from Microsoft and experienced DBAs is to stay within one or two cumulative updates of the current release. Falling too far behind means you're carrying known bugs and security vulnerabilities that have already been resolved. At the same time, applying every update the day it drops without testing is a risk in itself.

A practical patching approach for SQL Server 2016 SP2 looks like this:

  1. Subscribe to the Microsoft SQL Server Release Blog to get notified when new CUs are published.
  2. Review the KB article for each CU and identify fixes relevant to your workload.
  3. Apply the update to a development or test environment first.
  4. Allow a short soak period (typically 5 to 10 business days) to confirm stability.
  5. Schedule a production patch window and apply with a tested rollback plan.
  6. Document the update in your change management system.

For CU9 specifically, step 1 applies right now: wait for CU10 before proceeding.

Key Takeaways

  • Do not install SQL Server 2016 SP2 CU9 if you haven't already. An uninstall issue makes rollback unreliable. Wait for CU10, which Microsoft has committed to releasing on an expedited timeline.
  • If CU9 is already installed, your instance is running correctly. The uninstall bug only matters if you need to roll back. Plan to move to CU10 when available.
  • CU9 contains meaningful fixes covering transaction log truncation in single-node AGs, columnstore index correctness, In-Memory OLTP stability, and cardinality estimation improvements.
  • Patching discipline matters. Applying updates without a tested rollback path is a risk. This situation is a good reminder that patch testing and change management procedures exist for good reason.
  • Stay current with Microsoft's release blog to track when CU10 drops and review the KB notes before scheduling your patch window.

Keeping SQL Server environments patched, stable, and performing well is exactly what DBA Services does every day. If your team doesn't have a structured patching process in place, or if you want a second opinion on your current SQL Server 2016 environment, our managed support and health check services can help. We work with organisations across Australia to take the guesswork out of SQL Server maintenance. Get in touch to find out how we can help.