What Does SQL Server 2022 CU14 Fix?

SQL Server 2022 Cumulative Update 14 addresses six significant defects affecting backup reliability, Availability Groups synchronisation, Linux memory management, plan cache stability, and CPU overhead from Change Tracking. If you're running SQL Server 2022 in production, this update should be on your patching schedule. Several of the fixes address issues that can cause silent failures or misleading status indicators, which makes them particularly dangerous in environments where DBAs rely on automated monitoring.

Cumulative updates for SQL Server aren't optional reading. They're the primary mechanism Microsoft uses to deliver bug fixes between major service packs, and staying current reduces your exposure to known defects. CU14 was released for SQL Server 2022 and is cumulative, meaning it includes all fixes from CU1 through CU13 as well. You don't need to apply previous updates first.

The full release notes are available on the Microsoft support site.

Why Does Patching SQL Server Matter?

A lot of organisations treat SQL Server patching as a low-priority task, something to get to when there's time. That approach creates real risk. Known defects with documented fixes sitting unpatched in production environments are a common source of incidents that DBA teams get called in to resolve after the fact.

The fixes in SQL Server 2022 CU14 aren't cosmetic. They address backup failures, incorrect synchronisation status in high availability configurations, and memory management problems on Linux. Any one of those issues can cause an outage, data loss exposure, or a compliance problem depending on your environment.

What Are the Key Fixes in SQL Server 2022 CU14?

Here's a breakdown of the six primary fixes included in this cumulative update, with context on why each one matters in practice.

1. VSS Backups Can Fail After a Database Has Been Deleted

Volume Shadow Copy Service backups are commonly used in virtualised environments and by third-party backup tools that rely on VSS writers. If you had previously deleted a database from an instance, subsequent VSS backup operations could fail. The failure wasn't always obvious in the backup tool's logs, which meant some environments were running with incomplete backups without realising it.

This fix is important for any organisation using VSS-based backup solutions alongside SQL Server. If you've seen intermittent VSS backup failures and couldn't identify a clear cause, this may have been the underlying issue.

2. The SQL Server Launchpad Service Fails to Shut Down

The Launchpad service supports extensibility features in SQL Server, including R and Python execution through SQL Server Machine Learning Services. A defect in earlier builds meant the service could refuse to shut down gracefully, which caused problems during patching, restarts, and service maintenance windows.

In practice, this created situations where administrators couldn't complete a controlled restart without forcibly terminating the process. CU14 resolves the shutdown logic so the service responds correctly to stop commands.

3. Availability Groups Replicas Show "Not Synchronising" After a Successful Failover

This is one of the more serious fixes in the update. After a failover operation completed successfully, Availability Groups replicas could display a "Not Synchronising" status for several minutes. The actual data synchronisation was fine, but the status reporting was incorrect.

The danger here is obvious. If your monitoring tools alert on synchronisation status, you'd receive false positive alerts after every failover. Worse, if an operator saw that status and assumed the failover had failed, they might take corrective action that actually caused a problem. Accurate status reporting in high availability configurations isn't a nice-to-have, it's a fundamental operational requirement.

4. SQL Server on Linux May Ignore Configured Memory Limits

SQL Server on Linux supports memory configuration through both SQL Server settings and Linux control group (cgroup) limits. A defect meant SQL Server could ignore the memory limits set at the cgroup level, allowing the process to consume more memory than intended.

In containerised environments and on shared Linux hosts, this kind of memory overrun can destabilise other workloads or trigger out-of-memory conditions at the OS level. If you're running SQL Server in Docker, Kubernetes, or on a Linux host with other services, this fix is directly relevant to your environment's stability.

5. Plan Cache Leaks and Access Violations from Cardinality Estimation Feedback Race Conditions

Cardinality Estimation (CE) feedback is a SQL Server 2022 feature that allows the query optimiser to learn from execution history and adjust cardinality estimates over time. A race condition in the feedback mechanism could cause plan cache memory leaks and, in some cases, access violations.

Plan cache leaks degrade performance gradually. The cache fills with entries that can't be reused, forcing more frequent recompilation and increasing memory pressure. Access violations are more immediately disruptive, potentially causing process crashes. This fix addresses the thread safety issue in the CE feedback code path.

6. Change Tracking Auto Cleanup Consumes CPU Even When Change Tracking Is Disabled

Change Tracking is a SQL Server feature that records which rows have changed in tracked tables. The auto cleanup process removes old change tracking data to prevent unbounded growth. The defect was that the cleanup process was consuming CPU cycles even on databases where Change Tracking was not enabled.

In environments with many databases on a single instance, this unnecessary background activity could contribute to elevated CPU baselines. It wasn't catastrophic, but it was wasteful and could complicate capacity planning and performance troubleshooting.

How Should You Apply SQL Server 2022 CU14?

Applying a cumulative update to a production SQL Server instance requires planning. Here's the standard process:

  1. Review the release notes on the Microsoft support site to confirm which fixes are relevant to your environment.
  2. Download the update from the Microsoft Update Catalog or through Windows Update, depending on your patching process.
  3. Test in a non-production environment first. Apply the CU to a development or staging instance and validate your key workloads before touching production.
  4. Schedule a maintenance window. CU installation requires a SQL Server service restart. Plan for downtime or coordinate with your high availability configuration to minimise impact.
  5. Back up all databases before applying the update, including system databases.
  6. Apply the update and verify the build number after restart. For SQL Server 2022 CU14, the expected build number is 16.0.4145.4. You can confirm with SELECT @@VERSION.
  7. Monitor post-update. Watch error logs, performance metrics, and any alerts for at least 24 hours after applying the update.

For environments running Availability Groups, apply the update to secondary replicas first, fail over, then patch the remaining node. This approach minimises downtime and allows a rollback path if something unexpected occurs.

Key Takeaways

  • SQL Server 2022 CU14 fixes six significant defects, including issues with VSS backups, Availability Groups status reporting, Linux memory limits, plan cache stability, and unnecessary CPU usage from Change Tracking cleanup.
  • The Availability Groups "Not Synchronising" status bug is particularly dangerous because it produces misleading output that can trigger false alerts or incorrect operator responses.
  • SQL Server on Linux users should prioritise this update if they rely on cgroup memory limits to control resource consumption.
  • CU14 is cumulative and includes all fixes from CU1 through CU13, so you can apply it directly regardless of your current patch level within the SQL Server 2022 release.
  • Always test cumulative updates in a non-production environment before applying to production, and back up all databases beforehand.

Keeping SQL Server patched is straightforward in principle but often falls behind in practice, particularly in busy environments where production stability takes priority over maintenance work. If your SQL Server 2022 instances aren't current on cumulative updates, or if you're not sure what patch level they're running, that's worth addressing.

DBA Services provides SQL Server health checks and managed patching support for organisations across Australia. If you'd like an independent assessment of your SQL Server patch posture or help building a sustainable patching process, get in touch with our team.