SQL Server 2017 Cumulative Update 20: What You Need to Know Before You Apply It

SQL Server 2017 Cumulative Update 20 (CU20) is a significant patch release that delivers critical stability and reliability fixes across the database engine, virtualised environments, and Always On Availability Groups. If you're running SQL Server 2017 in production, this update addresses several high-impact bugs that can cause crashes, memory errors, and data availability issues. You should evaluate it for deployment, but there is one breaking change you need to understand before you apply it.

The porcelain packaging joke from the original announcement was a nod to the "china" gift tradition for 20th anniversaries. We'll leave that one there and focus on what actually matters for your environment.

What Does SQL Server 2017 CU20 Fix?

CU20 covers a broad range of fixes. The ones worth paying attention to are the issues that can cause unplanned downtime or silent data problems in production environments.

Database Engine Fixes

Out-of-memory errors caused by incorrect memory accounting. This is a particularly nasty class of bug. SQL Server reports memory pressure that doesn't reflect actual system state, which can cause queries to fail or the instance to throttle itself unnecessarily. Environments running under tight memory configurations or with Resource Governor policies in place are most likely to encounter this.

Unexpected SQL Server process crashes on VMware with hot-add CPU and memory. If your SQL Server VMs are configured to support hot-add resources (a common configuration in enterprise VMware environments), this bug could cause the SQL Server process to crash when those resources are dynamically added. This is a genuine operational risk for any organisation using VMware with dynamic resource scaling.

Access violation when querying computed columns. Computed columns are widely used for derived values and index optimisation. An access violation in this code path means potential crashes during routine query execution, not just in edge cases.

Crash during resumable rebuild of a filtered index on IS NULL. Resumable index rebuilds were introduced to reduce maintenance window pressure on large tables. A crash during this operation defeats the purpose entirely and can leave index maintenance incomplete.

Always On Availability Groups Fixes

Two fixes specifically target Always On AG behaviour:

  • Non-yielding scheduler on the primary replica. A non-yielding scheduler is a serious condition. It means a worker thread is not releasing the scheduler to allow other tasks to run, which eventually triggers a SQL Server health check failure and can force a failover or instance restart. This is not a minor inconvenience.
  • Missing log block on secondary replicas. Log block delivery is the core mechanism of synchronous and asynchronous AG replication. A missing log block can cause secondary replicas to fall behind or, in worst cases, trigger unnecessary failover events.

What Is the Breaking Change in CU20?

This is the part that requires your attention before you apply the update.

Copy-only differential backups are no longer allowed on AG secondaries after CU20 is applied.

If your backup strategy relies on taking copy-only differential backups from a secondary replica (a common pattern for offloading backup I/O from the primary), this change will break that workflow. The backup jobs will fail after the update is applied.

Microsoft documented this change in KB4495256. You can review the full details at the official Microsoft support article for CU20: https://support.microsoft.com/en-us/topic/kb4495256-cumulative-update-20-for-sql-server-2017-4cc4604e-9a27-194d-b2f2-1c2d92edf63e

The practical implication is straightforward: before you apply CU20, audit your backup jobs. If any of them are running copy-only differential backups against a secondary replica, you need to revise that strategy first. Options include moving those backups to the primary, switching to full copy-only backups on the secondary, or restructuring your backup chain entirely.

Don't skip this step. Finding out your backup jobs have been silently failing after a patch window is not a good outcome.

Should You Apply SQL Server 2017 CU20?

For most production environments, yes. The stability fixes in this update address real-world failure scenarios, particularly the VMware hot-add crash and the AG scheduler issue. These aren't theoretical bugs. They're the kind of issues that generate 2am incident calls.

Microsoft's general guidance is that cumulative updates for SQL Server are safe to apply to production environments and are tested to the same standard as service packs. That said, the standard advice applies: test in a non-production environment first, review the full list of fixes in the KB article, and make sure your backup and rollback plan is in place before you touch production.

A few practical steps before applying CU20:

  1. Review your backup strategy. Specifically check whether any backup jobs use copy-only differential backups on AG secondaries. Adjust before patching.
  2. Test in a lower environment first. Run the update against a dev or UAT instance that mirrors your production configuration, particularly if you're using VMware, computed columns, or resumable index rebuilds.
  3. Check your AG health before patching. Don't apply a cumulative update to an AG environment that already has synchronisation issues. Resolve any existing problems first.
  4. Schedule a maintenance window. CU installation requires a SQL Server service restart. Plan for downtime or use your AG failover process to apply the patch with minimal disruption.
  5. Verify the update level after installation. Run SELECT @@VERSION after the restart to confirm the build number reflects CU20 (14.0.3335.7).

Where Does SQL Server 2017 Stand in Its Lifecycle?

SQL Server 2017 reached end of mainstream support on 11 October 2022. It's now in the extended support phase, which runs until 12 October 2027. Microsoft will continue to release security updates and, where warranted, cumulative updates during extended support. But new features and non-security fixes become less common.

If you're still running SQL Server 2017, you're not in an unsupported position yet. But now is a reasonable time to start planning your upgrade path to SQL Server 2019 or SQL Server 2022, both of which bring meaningful improvements to query processing, availability features, and security. Extended support gives you a window, not a reason to delay indefinitely.

Key Takeaways

  • SQL Server 2017 CU20 fixes several high-severity bugs including a VMware hot-add crash, out-of-memory accounting errors, AG scheduler issues, and a computed column access violation.
  • There is one breaking change you must address before patching: copy-only differential backups are no longer supported on AG secondaries after CU20. Audit your backup jobs before applying this update.
  • Always On Availability Group environments should pay particular attention to the non-yielding scheduler and missing log block fixes, both of which address conditions that can trigger unplanned failovers.
  • SQL Server 2017 is in extended support until October 2027. CU20 is worth applying, but it's also a good prompt to assess your upgrade timeline.
  • Test before you deploy to production. This applies to every cumulative update, not just this one.

Keeping your SQL Server instances patched and properly configured is straightforward in principle but easy to let slip in busy environments. At DBA Services, our managed SQL Server support includes patch management, backup strategy reviews, and proactive health checks to catch exactly the kind of configuration issues that make updates like CU20 risky to apply. If you'd like a second opinion on your patching approach or your current SQL Server environment, get in touch with our team.