Introduction

Patching SQL Server involves choosing the right update, confirming you can recover if something goes wrong, and checking that the application works after the change. On a Windows server that hosts multiple SQL Server instances, you also need to confirm which instances and shared components the installer will update.

This guide uses a development and test example where a SQL Server 2019 instance moved from the original RTM build 15.0.2000.5 to 15.0.4500.2 using the CU32 + GDR security update, KB5128494. Microsoft released this update on 13 October 2026. Check Microsoft’s build history and the package prerequisites before selecting an update for your own environment. support.microsoft.com

1. Identify the current build on each instance

Connect to each SQL Server instance in SQL Server Management Studio (SSMS) and run:

SELECT @@VERSION;

For a result you can copy into a change ticket, use:

SELECT
    SERVERPROPERTY('ServerName') AS ServerName,
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductLevel') AS ProductLevel,
    SERVERPROPERTY('ProductUpdateLevel') AS ProductUpdateLevel;

Record the instance name and ProductVersion before patching. In this example, the same host also ran SQL Server 2025. The SQL Server 2019 update applied to the 2019 instance, so the 2025 instance was outside the patch scope. If the change requires a Windows restart, include both instances and their applications in the downtime plan.

2. Choose the right CU or GDR package

A Cumulative Update (CU) includes fixes from previous CUs for the same SQL Server version. Microsoft also publishes General Distribution Release (GDR) updates. The build history lists both GDR-only releases and security updates for the CU branch, labelled CU + GDR. Your installed build and your organisation’s servicing policy determine which package to choose. learn.microsoft.com

In the October 2026 release, Microsoft listed KB5128494 for the CU32 + GDR branch and KB5128495 for the GDR-only branch. Review the prerequisites and download the applicable package using the links in Microsoft’s support article. learn.microsoft.com

3. Verify backups and agree on a rollback plan

Book the maintenance window, notify application owners, and agree on when to stop troubleshooting and start recovery. Record the affected instances, current and target builds, expected downtime, and who will validate each application.

Use this query to review the latest recorded full, differential, and transaction log backups:

SELECT
    d.name AS DatabaseName,
    d.recovery_model_desc AS RecoveryModel,
    MAX(CASE WHEN b.type = 'D' THEN b.backup_finish_date END) AS LastFullBackup,
    MAX(CASE WHEN b.type = 'I' THEN b.backup_finish_date END) AS LastDifferentialBackup,
    MAX(CASE WHEN b.type = 'L' THEN b.backup_finish_date END) AS LastLogBackup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
    ON b.database_name = d.name
   AND b.type IN ('D', 'I', 'L')
WHERE d.name <> N'tempdb'
GROUP BY d.name, d.recovery_model_desc
ORDER BY d.name;

The query reads backup history from msdb. Confirm that the required backup files still exist, that the recovery team can access them, and that the restore sequence meets your recovery objectives. For databases using the Full or Bulk-Logged recovery model, check the transaction log backup chain where point-in-time recovery is required.

Document the recovery method before installing the patch. Depending on the environment, that could mean removing the update, recovering the VM, or restoring databases. An approved application-consistent VM snapshot can provide an additional recovery option alongside database backups.

4. Check disk space and resolve files in use

Check free space on the Windows system drive and any volumes the installer uses for extraction, temporary files, and setup logs. Review SQL Server service status and existing errors so you have a baseline for comparison after the change.

If Setup reports files in use, identify each process and the SQL Server instance or application it belongs to. Coordinate any service stop with the application owner, then rerun the readiness check. On a shared host, a process listed by Setup may belong to an application or service outside the original patch scope.

5. Install the update and review the setup result

  1. Run the Microsoft update installer using an approved administrative account.
  2. Review the readiness checks and resolve any blockers.
  3. Confirm the target SQL Server instance and review any shared components listed for update.
  4. Start the installation and record its outcome.
  5. Review the setup summary and logs for failed components, warnings, and restart requirements.
  6. Restart Windows if Setup requires it, within the approved maintenance window.

If a component fails, preserve the setup logs and use them to decide whether to troubleshoot within the remaining window or follow the agreed recovery plan.

6. Verify the build and test the application

Reconnect to the affected instance and rerun the version query. In this example, the SQL Server 2019 instance reported 15.0.4500.2 after installation, which matches the build listed for KB5128494. support.microsoft.com

Before closing the change:

  • Confirm the expected SQL Server and SQL Server Agent services are running.
  • Check that the databases are online and accessible.
  • Review the SQL Server error log and Windows Event Viewer for new errors.
  • Ask the application owner to confirm connectivity and run a representative business transaction.
  • Check that critical jobs, backups, integrations, and monitoring are working.
  • If Windows restarted, confirm the other instances and applications on the host recovered as expected.

Record the final build, actual downtime, validation results, and any follow-up work in the change ticket.

Need help planning a SQL Server update?

Onsys can help you review patch readiness, plan the maintenance window, and validate SQL Server and your applications after the change. Contact Onsys to discuss SQL Server patching support.