Why Cumulative Updates Matter for SQL Server Stability

Keeping SQL Server patched isn't optional if you care about stability and security. Microsoft's cumulative updates for SQL Server 2017 CU18 and SQL Server 2016 SP2 CU11 deliver targeted bug fixes for real, production-impacting issues including deadlocks, memory leaks, access violations, and replication failures. If you're running either of these versions without these updates applied, you're carrying known risk.

This article covers what's fixed in each update, why the specific fixes matter in practice, and how to approach deployment safely.

What's Fixed in SQL Server 2017 CU18?

SQL Server 2017 CU18 addresses a range of issues that have caused genuine pain in production environments. These aren't obscure edge cases. Several of the fixes target scenarios that come up regularly in busy OLTP and analytical workloads.

Replication on Linux now supported for snapshot and transactional replication. This is significant for organisations that have migrated SQL Server workloads to Linux and rely on replication for data distribution or reporting. Prior to CU18, running transactional or snapshot replication on SQL Server 2017 on Linux wasn't supported, which forced some shops to keep Windows instances in the mix purely for replication roles.

Deadlocks caused by concurrent inserts into clustered columnstore indexes. Columnstore indexes are widely used for analytical workloads and data warehousing. If you're running concurrent insert operations against a clustered columnstore index, this bug could cause deadlocks that are difficult to diagnose because they don't look like typical row-lock deadlocks. CU18 resolves this.

Access violation when restoring an In-Memory OLTP database. In-Memory OLTP (Hekaton) is used for high-throughput transaction processing. An access violation during restore is a serious issue, particularly in disaster recovery scenarios where restore time is critical. This fix removes a failure mode that could leave you unable to complete a restore under certain conditions.

Orphaned CLR sessions causing blocking. If your environment uses CLR integration for stored procedures or functions, orphaned sessions from CLR execution could cause blocking chains. This is the kind of issue that shows up as intermittent blocking that's hard to reproduce and frustrating to track down.

Update stats taking excessive time to build a query plan. Statistics maintenance is fundamental to query optimiser performance. If UPDATE STATISTICS is taking an abnormally long time to generate a query plan during execution, it creates a compounding problem: stats fall out of date, and the maintenance job itself becomes a performance issue. CU18 addresses this.

Access violations on adaptive joins. Adaptive joins were introduced in SQL Server 2017 as part of Intelligent Query Processing. Under certain conditions, they could trigger an access violation. If you've been seeing unexpected crashes or dump files related to query execution, this fix is relevant.

The full list of fixes in CU18 is documented in Microsoft KB article 4527377.

What's Fixed in SQL Server 2016 SP2 CU11?

SQL Server 2016 SP2 CU11 shares several fixes with CU18 for SQL Server 2017, and adds a few that are specific to SQL Server 2016 behaviour. SQL Server 2016 is still widely deployed in Australian enterprises, so these fixes remain operationally relevant.

Self-deadlock issue when auditing is enabled. SQL Server Audit is commonly used in regulated industries and government environments to meet compliance requirements. A self-deadlock in the audit subsystem is a particularly nasty bug because it can cause session hangs that are difficult to attribute to auditing without detailed investigation. This fix is important for any environment running SQL Server Audit.

Non-yielding scheduler issues related to parallel batch-mode sort operators. Non-yielding schedulers are serious. They can cause SQL Server to generate a dump file and, in severe cases, trigger a service restart. Parallel batch-mode sort is used in analytical queries, and this bug could destabilise the scheduler under load. If you've seen unexplained non-yielding scheduler errors in your SQL Server error log, this fix is worth applying immediately.

Memory leak on partitioned tables. Memory leaks are insidious because they accumulate over time. If your environment uses table partitioning for large tables (which is common in data warehousing and archiving scenarios), this bug could gradually consume buffer pool memory, degrading performance until a service restart clears it. CU11 resolves this leak.

Non-yielding schedulers caused by processing large numbers of row-column values in row groups. This is a second non-yielding scheduler fix, this one related to columnstore row group processing. Environments running large analytical queries against columnstore indexes are exposed to this issue.

The full fix list for SQL Server 2016 SP2 CU11 is in Microsoft KB article 4562935.

How Should You Deploy These Cumulative Updates?

Cumulative updates should never go straight to production without testing. The standard approach used by experienced DBAs follows a clear sequence.

Step 1: Review the KB article. Read the full list of fixes for your version. Identify which fixes are relevant to your environment. This helps you assess risk and prioritise urgency.

Step 2: Test in development first. Apply the update to a non-production environment that mirrors your production workload as closely as possible. Run your standard regression tests and check for any unexpected behaviour.

Step 3: Test in staging or UAT. Once dev looks clean, promote to staging. Run performance benchmarks if you have them. Check error logs after the update is applied.

Step 4: Schedule a production maintenance window. Plan the production deployment during a low-traffic window. Notify stakeholders. Have a rollback plan ready, which means a tested backup and a documented process to uninstall the CU if needed (though CU rollback is rarely required in practice).

Step 5: Monitor after deployment. Watch the SQL Server error log, Windows Event Log, and key performance metrics for at least 24-48 hours after applying the update in production. Look for anything unusual in wait stats, memory usage, and scheduler health.

One practical note: if your organisation has a change freeze over the holiday period, use that time to complete testing in lower environments so you're ready to deploy in the first maintenance window of the new year. Don't rush production deployments to hit an arbitrary deadline.

Should You Always Apply the Latest Cumulative Update?

Microsoft's recommendation is to apply the latest cumulative update for your SQL Server version. Cumulative updates are cumulative by design, meaning each one includes all fixes from previous updates. You don't need to apply them sequentially.

In practice, most experienced DBAs aim to stay within one or two CUs of the current release. Falling significantly behind means you're carrying multiple known bugs, some of which may be actively affecting your environment without your knowledge.

That said, some organisations apply a "wait and see" approach to very new CUs, waiting a few weeks after release to see if any issues are reported by the community. This is reasonable. Waiting more than 60-90 days without a specific reason is harder to justify.

Key Takeaways

  • SQL Server 2017 CU18 and SQL Server 2016 SP2 CU11 fix serious production issues including deadlocks, memory leaks, non-yielding schedulers, and access violations.
  • Several fixes are directly relevant to common enterprise workloads, including columnstore indexes, In-Memory OLTP, replication, and SQL Server Audit.
  • Always test cumulative updates in dev and staging before production deployment.
  • Microsoft recommends staying current with cumulative updates. Falling more than 2-3 CUs behind means carrying known, documented risk.
  • Non-yielding scheduler bugs in particular warrant urgent attention, as they can cause service instability under load.

If you're not sure which cumulative updates are applied across your SQL Server estate, or you want a second opinion on your patching process, DBA Services offers SQL Server health checks that cover patch currency, configuration review, and risk assessment. It's a practical way to get an independent view of where your environment stands.