sql server hub / patching guide

SQL Serverpatching guide

SQL Server patching is planned maintenance that moves an instance to a chosen, supported build. The plan should name the current build, target build, rollback path, HA sequence, and validation checks before the window starts.

Use this guide to plan SQL Server patching, choose between CU and GDR paths, check the instance before change, and validate the result after restart. Use the SQL Server latest updates tracker only for the current Microsoft build tables.

build

target

rollback

Guide

Guide~15 min readUpdated 23 May 2026

Share

LinkedInXEmail

What to decide before SQL Server patching

SQL Server patching should answer more than which installer to download. It should identify the current build, target build, servicing track, support state, rollback path, and validation owner before anyone starts the maintenance window.

The SQL Server latest updates tracker shows the current Microsoft build tables. This guide explains what to do with that information on a real SQL Server: when to patch, when to wait, and when the work is really an upgrade.

DecisionUseful output
Current buildProduct version, update level, KB reference, edition, and instance name.
Target buildCU, GDR, vendor-certified build, or upgrade path chosen deliberately.
Servicing trackWhether this is cumulative update work, narrower GDR work, or not routine patching.
Support stateMajor version, operating system, driver, and application support constraints understood.
Rollback pathUninstall, restore, failover, VM rollback, or rebuild path named before the window.
Validation ownerSQL checks and application checks assigned before the outage starts.

When SQL Server patching needs more planning

Routine patching assumes the major version is supported, the operating system is usable, backups and rollback are understood, and the application owner can validate the result. If those conditions are missing, a normal CU window can turn into a lifecycle or recovery problem.

Treat old builds, vendor-certified systems, HA redesign, compatibility concerns, or platform changes as planning work first. The patch may still be needed, but it should not be rushed through the same path as a small supported-version update.

TriggerWhat changes
Unsupported major versionPatch lookup is not enough; plan a supported version path.
Compatibility-level concernTest database behavior, query plans, and application assumptions.
OS dependencyServer OS support or driver dependency changes the work shape.
HA redesignAG/FCI topology, quorum, or failover design changes are upgrade work.
Migration target involvedIf the host/platform changes, use migration planning too.
Vendor certification gapThe app may require a specific build or major version path.

How to choose a SQL Server patch target

Start with the current build from SQL Server, then compare it with Microsoft build history, vendor certification, and the change window you actually have. The right target is not always the newest CU. It is the build you can install, support, validate, and recover from.

Use the SQL Server latest updates tracker for current Microsoft build tables. Use the SQL Server upgrade guide when the target requires a major-version move.

SituationLikely targetWhat to check
Routine supported-version patchUsually CU pathUse the tracker to compare current build with the latest CU for that major version.
Security-only conservative branchPossible GDR pathUse when the environment intentionally follows narrower security servicing.
Old unsupported major versionUpgrade discussionA CU/GDR lookup will not fix the lifecycle problem.
Vendor-certified build onlyCertified targetTarget the agreed build, not necessarily the newest CU.
HA or multi-replica estatePatch sequence firstThe target build matters, but ordering and validation matter just as much.

SQL Server patching build lookup

Start by reading the build from the server itself. Then compare `ProductVersion`, `ProductUpdateLevel`, and any KB reference against the SQL Server latest updates tracker. Do not choose a patch target from memory.

Current SQL Server version and build

Reads the current build, edition, update level, and KB/update reference from the instance.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY(N'MachineName') AS machine_name,
    SERVERPROPERTY(N'InstanceName') AS instance_name,
    SERVERPROPERTY(N'Edition') AS edition,
    SERVERPROPERTY(N'ProductVersion') AS product_version,
    SERVERPROPERTY(N'ProductLevel') AS product_level,
    SERVERPROPERTY(N'ProductUpdateLevel') AS product_update_level,
    SERVERPROPERTY(N'ProductUpdateReference') AS product_update_reference,
    SERVERPROPERTY(N'EngineEdition') AS engine_edition;

ProductVersion is the value to match against version-history tables. ProductUpdateLevel often shows CU or GDR level when SQL Server reports it. Edition can affect upgrade and feature decisions. Use this output before comparing anything in the tracker.

Instance uptime and platform context

Reads SQL Server start time, CPU, scheduler, memory, and VM context before planning a patch window.

SELECT
    si.sqlserver_start_time,
    DATEDIFF(hour, si.sqlserver_start_time, SYSDATETIME()) AS uptime_hours,
    si.cpu_count,
    si.scheduler_count,
    si.physical_memory_kb / 1024 AS physical_memory_mb,
    si.virtual_machine_type_desc
FROM sys.dm_os_sys_info AS si;

Recent uptime can explain why some monitoring counters have little history. Virtualized instances may need platform-level snapshot or rollback rules checked. CPU and memory shape help estimate restart and validation expectations. This does not check support status; it only describes the instance.

SQL Server patching CU vs GDR decisions

CU means cumulative update. It is the normal path when you want the latest fixes for a supported version. GDR is usually a narrower servicing path, often used for conservative security-focused updates. Do not compare build numbers without knowing which track you are following.

A server can be current for its chosen servicing track and still be behind the newest CU. Write down the chosen track before deciding whether the target is a CU, GDR, certified vendor build, or upgrade path.

TrackUse whenPlanning note
CUYou want the normal cumulative update path for a supported major version.Check release notes, vendor support, backups, rollback, and validation.
GDRThe environment intentionally follows the narrower security servicing track.Do not mix CU and GDR comparisons without understanding the branch.
Certified buildThe application vendor supports a named SQL Server build.Target the certified build unless the vendor confirms a newer one.
Upgrade pathThe major version, OS, or compatibility state makes patching too small a fix.Move to upgrade planning before scheduling a normal patch window.

SQL Server patching plan before the window

Before the window starts, the patch plan should be boring and specific. Current build, target build, backup point, rollback trigger, owner, and validation steps should already be written down.

Planning itemWhat good looks likeWhy it matters
Current buildKnown from SQL output, not a screenshot or memory.Required before any comparison.
Target buildChosen CU, GDR, certified build, or upgrade target.Must be named before the window.
Supported versionMajor version and support status checked.If unsupported, this may be upgrade work.
Last good backupRecent full/log chain or agreed backup point.Rollback is weak when restore testing is missing or too old.
Rollback triggerSpecific failure point or time limit.Example: app smoke test fails after 30 minutes.
Maintenance windowEnough time for patch, restart, validation, and fallback.Do not spend the whole window installing.
Application ownerSomeone can validate the real business workflow.SQL online is not the same as app healthy.
HA/AG sequenceReplica order, failover behavior, and sync checks known.Primary and secondary patch order must be deliberate.

SQL Server patching sequence for single instances and AGs

The exact installer work is usually simple. The sequence around it is where SQL Server patching succeeds or gets messy. Use these as starting runbooks and adjust them for your application, HA design, and rollback rules.

Single SQL Server instance

Use this for one standalone SQL Server instance where a planned restart is acceptable.

  1. 1Confirm current build, target build, support status, edition, and instance name.
  2. 2Confirm recent backups and the rollback decision point before the window starts.
  3. 3Stop or pause application traffic if the app team requires a clean outage.
  4. 4Disable or hold jobs that must not overlap the patch, such as ETL, index maintenance, or long reporting jobs.
  5. 5Install the SQL Server update package and restart the server or service if required.
  6. 6Run the post-patch build check and confirm the target build is installed.
  7. 7Confirm databases are online, SQL Agent is running, and critical jobs are enabled again.
  8. 8Run application smoke tests with the app owner before releasing the window.
  9. 9Watch the error log, jobs, backups, and top workload for the first normal business cycle.

Availability Group patch sequence

Use this when replicas protect the same databases and failover order matters.

  1. 1Confirm AG health, synchronization state, listener name, backup preference, and current primary replica.
  2. 2Patch secondary replicas first, one at a time, while keeping databases synchronized.
  3. 3After each secondary patch, restart as needed and confirm the replica rejoins and synchronizes.
  4. 4Fail over to a patched secondary during the agreed window, using the planned failover method.
  5. 5Validate the application against the new primary and confirm listener connectivity.
  6. 6Patch the former primary after it is safely secondary.
  7. 7Fail back only if the plan requires it; otherwise leave the patched replica as primary if that is acceptable.
  8. 8Confirm AG synchronization, backup preference, jobs, alerts, and application validation after all replicas are patched.
  9. 9Keep monitoring send queue, redo queue, error log, and app behavior after normal traffic returns.

Multiple standalone SQL Server instances

Use this when several independent instances need the same or related patch work.

  1. 1Group instances by business criticality, version, vendor constraint, maintenance window, and rollback option.
  2. 2Patch one lower-risk instance first as the pilot, not the most critical production server.
  3. 3Record install time, restart time, validation time, issues, and final build from the pilot.
  4. 4Adjust the runbook before patching the next group.
  5. 5Patch remaining instances in batches small enough that rollback and validation are still realistic.
  6. 6Avoid patching every environment at once when the same application or vendor dependency exists everywhere.
  7. 7Track each instance with current build, target build, status, validation owner, and open issues.
  8. 8Confirm central monitoring, backups, SQL Agent jobs, and application checks after each batch.
  9. 9Keep the final estate report: patched, deferred, failed, rollback used, and follow-up action.

SQL Server pre-patch checks

Pre-patch checks are not there to make the page longer. They reduce surprises: old compatibility levels, disabled Query Store, stale backups, failed jobs, or AG health problems can turn a normal CU into a longer outage.

Database compatibility and Query Store flag

Lists user database state, compatibility level, recovery model, read-only flag, and Query Store flag.

SELECT
    name AS database_name,
    state_desc,
    compatibility_level,
    recovery_model_desc,
    is_read_only,
    is_query_store_on
FROM sys.databases
WHERE name NOT IN (N'master', N'model', N'msdb', N'tempdb')
ORDER BY name;

Compatibility levels matter more for upgrades, but they are useful patch context. Read-only databases and unusual states should be known before the window. Query Store can help compare workload behavior after patching. This does not test the application; it only records database state.

Query Store state

Shows Query Store desired and actual state plus storage usage for user databases.

SELECT
    d.name AS database_name,
    d.is_query_store_on,
    qso.actual_state_desc,
    qso.desired_state_desc,
    qso.readonly_reason,
    qso.current_storage_size_mb,
    qso.max_storage_size_mb
FROM sys.databases AS d
LEFT JOIN sys.database_query_store_options AS qso
    ON qso.database_id = d.database_id
WHERE d.name NOT IN (N'master', N'model', N'msdb', N'tempdb')
ORDER BY d.name;

Actual state can differ from desired state. A read-only Query Store may not capture useful post-patch data. Storage limits can explain missing or incomplete runtime history. Run this before the window if you plan to use Query Store for validation.

Availability Group health

Checks AG replica role, replica health, database sync state, and send/redo queues where AGs are configured.

SELECT
    ag.name AS availability_group_name,
    ar.replica_server_name,
    ars.role_desc,
    ars.synchronization_health_desc AS replica_health,
    drs.database_id,
    DB_NAME(drs.database_id) AS database_name,
    drs.synchronization_state_desc,
    drs.synchronization_health_desc AS database_health,
    drs.log_send_queue_size,
    drs.redo_queue_size
FROM sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ar.group_id = ag.group_id
LEFT JOIN sys.dm_hadr_availability_replica_states AS ars
    ON ars.replica_id = ar.replica_id
LEFT JOIN sys.dm_hadr_database_replica_states AS drs
    ON drs.replica_id = ar.replica_id
ORDER BY ag.name, ar.replica_server_name, database_name;

If this returns no rows, the instance may not host availability groups. Patch sequence depends on replica roles and synchronization health. Large send or redo queues should be understood before patching. AG health should be checked again after patching.

Recent backup history

Shows the latest full, differential, and log backups found in msdb for the last 14 days.

WITH LastBackups AS (
    SELECT
        bs.database_name,
        bs.type,
        bs.backup_start_date,
        bs.backup_finish_date,
        bs.backup_size,
        bs.compressed_backup_size,
        ROW_NUMBER() OVER (
            PARTITION BY bs.database_name, bs.type
            ORDER BY bs.backup_finish_date DESC
        ) AS rn
    FROM msdb.dbo.backupset AS bs
    WHERE bs.backup_finish_date >= DATEADD(day, -14, GETDATE())
)
SELECT
    database_name,
    CASE type
        WHEN 'D' THEN 'Full'
        WHEN 'I' THEN 'Differential'
        WHEN 'L' THEN 'Log'
        ELSE type
    END AS backup_type,
    backup_start_date,
    backup_finish_date,
    DATEDIFF(minute, backup_start_date, backup_finish_date) AS duration_minutes,
    CONVERT(decimal(18,2), compressed_backup_size / 1048576.0) AS compressed_size_mb
FROM LastBackups
WHERE rn = 1
ORDER BY database_name, backup_type;

This shows backup history in msdb, not that restores are tested. Log backup cadence matters for full recovery model databases. Missing recent backups should stop routine patching until recovery is clear. Use the recovery guide when restore testing is missing or too old.

Recent failed or long SQL Agent jobs

Shows recent failed job steps or steps longer than 30 minutes from msdb job history.

SELECT TOP (100)
    j.name AS job_name,
    h.step_id,
    h.step_name,
    h.run_status,
    msdb.dbo.agent_datetime(h.run_date, h.run_time) AS run_start_time,
    ((h.run_duration / 10000) * 3600)
      + (((h.run_duration % 10000) / 100) * 60)
      + (h.run_duration % 100) AS duration_seconds,
    h.message
FROM msdb.dbo.sysjobhistory AS h
JOIN msdb.dbo.sysjobs AS j
    ON j.job_id = h.job_id
WHERE h.run_date >= CONVERT(int, CONVERT(char(8), DATEADD(day, -14, GETDATE()), 112))
  AND (h.run_status <> 1 OR h.run_duration >= 3000)
ORDER BY run_start_time DESC, duration_seconds DESC;

Recent failures can become false blame after patching if they are not known first. Long jobs can overlap with maintenance windows. Job history retention may hide older patterns. Check critical app, backup, ETL, and maintenance jobs before the window.

SQL Server patching rollback planning

Patch uninstall, VM rollback, restore, and failover are different fallback paths. A rollback plan should name which one is realistic, how long you will spend trying to fix the patch, and who decides to stop.

Rollback itemWrite downWarning
Backup before patchConfirmed full/log chain or recovery point.A backup job that merely ran is not enough if restore has not been tested recently.
Snapshot policyAllowed or rejected by platform policy.Useful in some VM setups, but not a replacement for SQL recovery planning.
Patch package savedInstaller and KB target available locally.Do not rely on finding the package during rollback stress.
Rollback time limitDefined before the window.Example: stop after 45 minutes if SQL or app validation fails.
Validation ownerNamed app or business owner.DBA checks cannot test every app workflow.
Fallback optionUninstall, restore, failover, or rebuild path.Know which option is realistic for this environment.

SQL Server post-patch validation

Post-patch validation should check more than “SQL Server started.” Confirm the new build, database state, Agent jobs, error log, AG health if present, application workflows, and the next backup.

Post-patch validation starter

Checks the new build, database state, and recent SQL Agent job history after the patch.

SELECT
    SERVERPROPERTY(N'ProductVersion') AS product_version,
    SERVERPROPERTY(N'ProductLevel') AS product_level,
    SERVERPROPERTY(N'ProductUpdateLevel') AS product_update_level,
    SERVERPROPERTY(N'ProductUpdateReference') AS product_update_reference;

SELECT
    name,
    state_desc,
    user_access_desc,
    recovery_model_desc
FROM sys.databases
ORDER BY name;

SELECT TOP (50)
    j.name AS job_name,
    h.step_id,
    h.step_name,
    h.run_status,
    msdb.dbo.agent_datetime(h.run_date, h.run_time) AS run_start_time,
    h.message
FROM msdb.dbo.sysjobhistory AS h
JOIN msdb.dbo.sysjobs AS j
    ON j.job_id = h.job_id
WHERE h.run_date >= CONVERT(int, CONVERT(char(8), DATEADD(day, -2, GETDATE()), 112))
ORDER BY run_start_time DESC;

The first result set should match the target build. Database state should be reviewed before application validation starts. Agent failures after patching should be separated from failures that already existed. This is a starter; add app-specific validation and AG checks where needed.

Validation areaWhat to confirmWhy it matters
Build numberNew build matches the target.Run the build query after restart.
SQL servicesEngine and Agent are running.Check service state and SQL Agent job startup.
DatabasesExpected databases online.No suspect/recovery state surprises.
JobsCritical jobs succeed or are intentionally held.Check recent failures after patching.
Error logNo repeated startup, stack dump, login, or recovery errors.Review immediately and again after normal workload resumes.
Query Store/workloadNo obvious regression in top queries or waits.Watch top queries and wait patterns after the app is active.
AG/HAReplicas synchronized and failover posture expected.Check AG health before declaring the work done.
BackupNext backup job succeeds.A patch window is not done until protection resumes.

SQL Server patching mistakes to avoid

MistakeResult
Comparing builds without CU/GDR contextWrong conclusion about what is newer or appropriate.
Choosing newest without vendor/application supportA technically current build that the app owner cannot support.
No restore-tested backupRollback depends on an untested recovery path.
No post-patch validation ownerSQL starts, but the business workflow is still untested.
Patching AG replicas without a sequenceUnexpected failover, sync, or backup preference trouble.
Treating unsupported versions as normal patchingThe real problem remains after the maintenance window.

Patch review

Need a SQL Server patch review?

Get in touch for a SQL Server patch review before the maintenance window.

Next step

Use the SQL Server latest updates tracker for current Microsoft-sourced build tables.

If patching has become a version, rollback, HA, or compatibility problem, read the SQL Server upgrade guide, use SQL Server upgrade support, or start from SQL Server consulting.