Applying a SQL Server Cumulative Update (CU)

Applies a Cumulative Update (CU) within the same major version to an installed SQL Server 2022/2025 instance: with dnf/apt on Linux, as a silent (/quiet) installation with the CU setup file on Windows. Single server, or rolling in an Always On AG (secondaries first, failover, then the old primary; with Pacemaker on Linux). Pre-checks, a COPY_ONLY backup, verification and rollback are included; at the end all replicas are on the same CU and healthy.

A major version upgrade (e.g. 2019 → 2022) is outside the scope of this guide. For a new installation see the Linux or Windows installation guides; for day-to-day AG operations see AG operations.

Topology: 1 server or an AG (2+ replicas)

Before you start

• The CU to apply has been chosen and its KB notes (known issues, prerequisites) have been read. …Target: ………the latest CU in the repository….…Setup file … …at the same path on every node…on the server….…
• The CU was applied in a test/pre-production environment first and the application tests passed.
• The maintenance window is approved and the application teams have been informed. …In a rolling update there is a short outage (seconds) only at failover.…On a single server the service is restarted (an outage of a few minutes).…
• A server snapshot (virtual machine) or an OS-level restore point can be taken.
• At least 2 GB free under /var/opt/mssql and /opt; the backup directory (…) has room for a compressed full backup of all databases.
• The server can reach the SQL Server … repository (the new CU must already be in the repository).
• The sqlcmd steps connect as …. Before running the script: read -rsp 'Password: ' SQLCMDPASSWORD; export SQLCMDPASSWORD and sudo --preserve-env=SQLCMDPASSWORD bash <script>.sh.
• At least 6 GB free on the system drive; no pending Windows restart; SSMS and other tools connected to SQL Server are closed. PowerShell is opened as administrator with a Windows account that has sysadmin rights; sqlcmd is in the PATH.
• The AG is healthy: all replicas connected, databases synchronized, the failover target (…) is SYNCHRONOUS_COMMIT. If there are only asynchronous replicas, switch one to synchronous first.
• The Pacemaker cluster is healthy (pcs status without errors, fencing works); AG resource ….

Phases of the guide

• Pre-checks — Record the current version and list the versions in the repository · Record the current version and list the versions in the repository: … · Pre-download the new version · Pre-download the new version: … · Check the setup file and the server · Check the setup file and the node: … …
• Backup and fallback point — Take a COPY_ONLY backup of all databases · Take a COPY_ONLY backup of all databases · Take a server snapshot
• Apply the CU (single server) — Stop application connections · Stop application connections · Update SQL Server · Install the CU silently
• Rolling CU (Windows AG) — Temporarily disable automatic failover · Update the additional secondary: … · Update the failover target: … · Verify that the updated secondaries are synchronized · Failover: make … the primary · Update the old primary: … …
• Rolling CU (Linux AG) — Update the additional secondary: … · Update the additional secondary: … · Update the failover target: … · Update the failover target: … · Verify that the updated secondaries are synchronized · Failover: make … the primary (Pacemaker) …
• Verification — Verify the version and CU level · Verify the version and CU level: … · Verify the version and CU level · Verify the version and CU level: … · Check the errorlog for upgrade errors · Check the errorlog for upgrade errors …
• Rollback (if needed) — Return to the previous version · Uninstall the CU · Verify the version after the rollback · Verify the version after the rollback