SQL Server 2019 Cumulative Update 7: What Happened and What You Need to Know

Microsoft released Cumulative Update 7 (CU7) for SQL Server 2019 in September 2021, then pulled it almost immediately after a critical defect surfaced affecting database snapshots and CHECKDB operations. If you were tracking this update and wondering why it disappeared from the download page, that's why. The short version: CU7 contained genuinely useful fixes, but a post-release bug made it unsafe to deploy until Microsoft resolved the underlying issue.

This kind of situation is exactly why a disciplined patching process matters. Organisations that rush to apply cumulative updates the day they drop are the ones most likely to get caught out. Those with a structured testing and staging process have time to catch exactly this sort of problem before it reaches production.

What Was Actually Fixed in SQL Server 2019 CU7?

Despite the rocky release, the fixes included in CU7 addressed real, documented problems that were affecting production environments. Here's a summary of the most significant ones.

Columnstore index hangs on concurrent inserts

Concurrent inserts against tables with columnstore indexes were causing queries to hang. This is a serious issue in high-throughput OLTP environments that also use columnstore indexes for analytical workloads, a pattern that's increasingly common in mixed workload databases. If you were seeing unexplained blocking or hanging queries on tables with columnstore indexes, this fix was directly relevant.

Incorrect row counts in Read Committed Snapshot Isolation

SELECT queries were returning an incorrect number of rows when run under Read Committed Snapshot Isolation (RCSI) on a Clustered Columnstore Index (CCI). Wrong row counts from a SELECT statement is the kind of bug that erodes confidence in your data platform fast. RCSI is widely used in busy OLTP environments to reduce blocking, so this affected a broad range of deployments.

Ghost row inconsistency in mapping index rowset

An inconsistency was occurring when ghost rows were inserted into a mapping index rowset. Ghost rows are a normal part of SQL Server's row versioning and cleanup process, but inconsistencies in the mapping index can lead to data integrity concerns and complicate DBCC CHECKDB results.

Intermittent Availability Group failover

Intermittent, unexpected failovers in an Always On Availability Group environment are one of the most disruptive problems a DBA can face. CU7 included a fix targeting this behaviour. If you were seeing unexplained failovers and had ruled out network and hardware causes, this was worth investigating.

Long waits with DTC_STATE wait type in distributed transactions

Distributed transactions using the Microsoft Distributed Transaction Coordinator (MSDTC) were generating long waits on the DTC_STATE wait type. This manifests as performance degradation in applications that rely on cross-database or cross-server transactions.

New message 47149 for contained availability groups

CU7 added a new entry to sys.messages. Message 47149 warns users that they cannot start a SQL Agent job on the secondary replica of a contained availability group, and that the job should be started on the primary replica instead.

This is worth clarifying, because the terminology is easily confused. Contained availability groups in this context refers to availability groups used within SQL Server Big Data Clusters that can contain system databases. This is distinct from the concept of contained databases used with traditional Always On Availability Groups. If you're running Big Data Clusters, this message provides clearer operational guidance when jobs are targeted at the wrong replica.

Why Did Microsoft Pull the Update?

Shortly after release, Microsoft identified a defect in CU7 that affected database snapshots and DBCC CHECKDB. Both of these are foundational to database integrity and maintenance operations.

Database snapshots are used for a range of purposes including readable secondaries in Availability Groups, certain backup strategies, and point-in-time reporting. DBCC CHECKDB is the primary tool for verifying database integrity. Any bug that interferes with either of these is a showstopper.

Microsoft's decision to pull the update was the right call. Releasing a cumulative update that breaks CHECKDB would undermine the very integrity guarantees that SQL Server is built on. The update was subsequently revised and re-released once the issue was resolved.

Should You Install SQL Server 2019 CU7?

Yes, but through your normal testing process. The revised version of CU7 addressed the snapshot and CHECKDB issue. The fixes it contains are legitimate and address documented production problems. Microsoft's guidance is generally to stay current with cumulative updates, and that remains sound advice for most environments.

Before applying any cumulative update to a production SQL Server instance, follow these steps:

  1. Review the full release notes on the Microsoft support page (KB5004242 for CU7) and read every fix description, not just the headlines.
  2. Check the Microsoft Known Issues section of the KB article. Microsoft documents known problems at release time when they're aware of them.
  3. Apply the update to a non-production environment first. Ideally this mirrors your production configuration, including the same SQL Server edition, Windows Server version, and database workload characteristics.
  4. Run DBCC CHECKDB on all databases after applying the update in your test environment. This is standard practice and catches integrity issues early.
  5. Monitor for the specific symptoms addressed by the fixes. If you were experiencing columnstore hangs or RCSI row count issues, verify those are resolved in your test environment before promoting to production.
  6. Schedule production deployment during a maintenance window with a tested rollback plan. Cumulative updates can be uninstalled, but it's a disruptive process you'd rather not execute under pressure.

What Does This Mean for Your Patching Strategy?

The CU7 situation is a useful case study in why "install updates immediately" is not a patching strategy. It's a risk posture. Microsoft's own release process, as rigorous as it is, occasionally produces updates that need to be revised. That's not a criticism. It's the operational reality of maintaining a complex, widely deployed platform like SQL Server.

A practical SQL Server patching strategy for most organisations looks something like this:

  • Wait 2-4 weeks after a cumulative update is released before deploying to production. This gives the community time to surface issues Microsoft may have missed.
  • Subscribe to the SQL Server release blog and relevant Microsoft support notifications so you're aware of pulls or revisions quickly.
  • Maintain a staging environment that's representative of production. The closer it is to production, the more confidence you get from testing there.
  • Document your current CU level and track when you last patched. Environments running more than 2-3 cumulative updates behind current are accumulating known bug exposure unnecessarily.
  • Treat security-related cumulative updates with more urgency. Some CUs include fixes for CVEs, and those have a different risk calculus than general bug fixes.

Microsoft publishes the latest cumulative update information for all SQL Server versions at aka.ms/sqlserverbuilds. Bookmark it. Check it regularly.

Key Takeaways

  • SQL Server 2019 CU7 was released and then pulled due to a defect affecting database snapshots and DBCC CHECKDB. It was subsequently revised and re-released.
  • The update contains important fixes for columnstore index hangs, incorrect RCSI row counts, intermittent Availability Group failovers, and DTC_STATE wait type performance issues.
  • Never apply a cumulative update directly to production. Always test in a staging environment first and run DBCC CHECKDB after applying.
  • A 2-4 week wait period after a CU release is a reasonable buffer to allow the community to surface any post-release issues before you deploy.
  • Stay current with SQL Server patching. Running multiple cumulative updates behind current means carrying known bugs that Microsoft has already fixed.

Keeping SQL Server patched and healthy is one of the most impactful things you can do for database stability and security, and it's also one of the most commonly deferred tasks in busy IT environments. DBA Services provides managed SQL Server support and proactive health checks that include patch management, ensuring your instances stay current without the risk of unplanned downtime. If your SQL Server patching is overdue or your team doesn't have a structured process in place, get in touch to find out how we can help.