SQL Server 2019 Cumulative Update 2: What You Need to Know Before Installing

SQL Server 2019 Cumulative Update 2 (CU2) was released by Microsoft in February 2020 and delivers fixes for over 20 documented bugs across backup, availability groups, security, memory, and query execution. However, this update carries a critical warning: Microsoft confirmed after release that CU2 can break SQL Server Agent, and the official recommendation at the time was to uninstall it and wait for a corrected build.

If you're managing a SQL Server 2019 environment, that warning alone should give you pause. This article breaks down what CU2 fixes, what it breaks, and what the release pattern tells you about managing new SQL Server versions in production.

Why Does SQL Server 2019 CU2 Matter?

Cumulative updates for SQL Server 2019 matter more than usual during the first year of a major release. SQL Server 2019 introduced a significant number of new features, including Accelerated Database Recovery (ADR), memory-optimised TempDB metadata, scalar UDF inlining, and Big Data Clusters. Each of those features carries risk until it's been battle-tested across thousands of production environments.

CU2 is notable because it fixes bugs introduced by some of those headline features, while also introducing a regression that breaks SQL Server Agent. That combination is exactly why experienced DBAs treat new SQL Server versions with caution.

What Does SQL Server 2019 CU2 Fix?

The update addresses bugs across several functional areas. Here's a breakdown of the key fixes.

Corruption and Data Integrity Bugs

The most serious fix in CU2 addresses silent data corruption in Accelerated Database Recovery. ADR was one of the flagship features of SQL Server 2019, designed to dramatically reduce recovery time and enable instant rollback of long-running transactions. Finding a silent corruption bug in that feature is significant. Silent corruption is the worst kind because you may not know it's happening until you try to recover data and find it's wrong.

Server Stability Bugs

CU2 resolves several bugs that caused SQL Server to crash or become unresponsive:

  • Out-of-memory errors caused by incorrect memory accounting
  • Server crashes when running DBCC CHECKTABLE against a columnstore index
  • Non-yielding scheduler errors when sorting on NVARCHAR columns
  • Floating point exceptions when executing stored procedures
  • Errors when combining encryption with UNION queries

Any one of these issues could bring down a production server. The CHECKTABLE bug is particularly concerning for shops running regular integrity checks, which every well-managed environment should be doing.

Security Vulnerabilities

Two security-related bugs were fixed in this update:

  • Passwords appearing in clear text in SQL Server audit logs
  • Encryption failures with symmetric keys

The audit log issue is serious from a compliance perspective. If your organisation is subject to any data protection requirements, having passwords written to audit logs in clear text is a breach waiting to happen. Patching this promptly, once a stable build is available, should be a priority.

Query Execution and Performance Bugs

  • Memory leaks caused by scalar UDF inlining, another SQL Server 2019 feature that was introduced to automatically inline scalar functions for better performance
  • Log reader agent not running correctly
  • SSIS running slower in SQL Server 2019 compared to earlier versions

The scalar UDF inlining memory leak is worth noting. Inlining was a well-publicised performance improvement in 2019, but a memory leak in that code path could cause gradual memory pressure on busy servers, which is the kind of bug that's hard to diagnose without knowing to look for it.

Backup and Recovery Bugs

  • SQL Server 2012 databases with nonclustered columnstore indexes could not be restored
  • VSS backups could freeze I/O and fail to resume, effectively hanging the server
  • Log shipping agent could not log history or errors

The VSS backup freeze is a critical bug for any environment using VSS-based backup tools, which includes many third-party backup products and Windows Server Backup. A frozen I/O operation doesn't just break the backup; it can impact the entire SQL Server instance.

Availability Group Bugs

  • Linux Distributed Availability Groups (DAG) not syncing after failover
  • Deadlock in contained AG master database

These fixes are relevant to organisations running SQL Server 2019 on Linux or using contained availability groups, both of which are relatively new capabilities.

DMV and TempDB Bugs

  • Users unable to query sys.dm_exec_requests in certain scenarios
  • Memory-optimised TempDB metadata fixes to speed up two additional system tables
  • Users unable to query TempDB DMVs after changing isolation level

The TempDB metadata fixes are incremental improvements to the memory-optimised TempDB feature introduced in SQL Server 2019. That feature reduces contention on system tables in TempDB-heavy workloads, but it clearly needed additional work to cover more scenarios.

What Does CU2 Break?

After CU2 was released, Microsoft identified a regression that breaks SQL Server Agent. SQL Server Agent is the job scheduling engine that runs backups, maintenance plans, ETL jobs, alerts, and virtually every automated task in a typical SQL Server environment. Breaking Agent is not a minor inconvenience. It can silently stop all your scheduled jobs, including backups, without obvious errors that would trigger alerts.

Microsoft's recommendation was to uninstall CU2 and wait for a corrected release. This is the right call. A cumulative update that introduces a regression in a core component should not be running in production.

Should You Install SQL Server 2019 CU2?

At the time of its original release, the answer was no. The SQL Server Agent regression made CU2 unsuitable for production use. If you're reading this now and you're still running SQL Server 2019 at an older patch level, the right approach is to check the current latest cumulative update for SQL Server 2019 and apply that instead. Microsoft has released many subsequent cumulative updates that include all the CU2 fixes without the regression.

The broader lesson here is one that experienced DBAs know well: don't rush to apply cumulative updates the day they're released, especially on a major version that's less than 12 months old. Wait at least 2-4 weeks after a CU release to see whether any regressions are reported by the community. The SQL Server community is large and active, and serious bugs tend to surface quickly on forums, blogs, and Microsoft's feedback channels.

What Does This Tell Us About New SQL Server Versions?

SQL Server 2019 CU2 is a good case study in why you shouldn't run a brand-new SQL Server version in production within the first 60-90 days of its release. The first 6-12 months of any major SQL Server release tend to produce the most significant bug fixes, as Microsoft and the broader community discover issues that didn't surface in testing.

The pattern is consistent across SQL Server versions. SQL Server 2017, 2016, and 2014 all had significant bug fixes in their early cumulative updates. Planning your upgrade timeline to allow for at least 6 months of post-release patching before you migrate production workloads is a reasonable and defensible position.

For organisations on SQL Server 2019, the priority right now is to ensure you're running a recent, stable cumulative update rather than any build from the first year of release.

Key Takeaways

  • SQL Server 2019 CU2 fixes over 20 bugs including a silent data corruption issue in Accelerated Database Recovery, a VSS backup freeze, and passwords appearing in clear text in audit logs.
  • CU2 introduced a regression that breaks SQL Server Agent, making it unsuitable for production use. Microsoft recommended uninstalling it.
  • If you're still on an early SQL Server 2019 build, skip CU2 and apply the latest available cumulative update instead.
  • New SQL Server versions typically require 6-12 months of cumulative updates before they stabilise. Plan upgrade timelines accordingly.
  • Security-related bugs in CU2, particularly the audit log password exposure, make staying current on patching a compliance issue, not just a stability issue.

Need Help Managing SQL Server Patching?

Keeping SQL Server environments patched correctly, without introducing regressions or missing critical security fixes, requires more than just downloading updates when they're released. It requires testing, scheduling, rollback planning, and awareness of what each update actually does.

DBA Services provides managed SQL Server support and health checks for Australian organisations running SQL Server across all versions. If you're unsure whether your SQL Server 2019 environment is on a stable, secure build, a health check is the fastest way to find out. Contact us to discuss what your environment needs.