Mettre à jour SQL Server : CU, GDR et branches de maintenance

Cette page décrit le modèle de maintenance de SQL Server 2017 et suivants, sur Windows. Les numéros de build cités sont réels et datés du 12 septembre 2026.

CU et GDR

Microsoft a abandonné les Service Packs avec SQL Server 2017, en adoptant le Modern Servicing Model. Il reste deux types de mises à jour :

Les CU sont cumulatives : chacune contient toutes les précédentes. Vous pouvez passer directement du RTM à la dernière CU sans installer les intermédiaires.

À la fin du support standard, Microsoft cesse de publier des CU. La version ne reçoit plus que des GDR, jusqu’à la fin du support étendu :

Les deux branches de maintenance

flowchart LR
    RTM["RTM"] --> GDR1["GDR"]
    GDR1 --> GDR2["GDR suivant"]
    RTM --> CU1["CU1"]
    CU1 --> CUN["CU2 … CUn"]
    CUN --> CUGDR["CUn + GDR"]
    GDR1 -. "CU + GDR plus récent" .-> CUGDR

À partir du RTM, chaque version se sépare en deux branches :

• la branche GDR, qui ne reçoit que les correctifs de sécurité et les correctifs critiques ;
• la branche CU, qui reçoit ces mêmes correctifs et tous les autres.

Dès que vous installez une CU, l’instance passe sur la branche CU et y reste. Revenir sur la branche GDR demanderait de désinstaller toutes les CU. Personne n’a de raison de le faire, puisque la branche CU contient déjà toute la sécurité.

Le passage de la branche GDR à la branche CU est possible, mais pas avec n’importe quelle CU. La CU que vous installez doit contenir les correctifs de sécurité du GDR déjà en place, donc avoir été publiée le même jour ou après lui. Prenez la build la plus récente de la branche CU. Une CU plus ancienne que le GDR installé est refusée par l’installateur, avec le message « There are no SQL Server instances or shared features that can be updated on this computer ».

Je recommande la branche CU. Le RTM d’une version contient des bogues corrigés dans les premières CU, et une instance restée sur la branche GDR ne recevra jamais ces corrections.

Lire le numéro de build

La fonction SERVERPROPERTY donne la build, le niveau de CU et l’article KB correspondant :

-- Version, niveau de mise à jour et article KB de l'instance
SELECT SERVERPROPERTY('ProductVersion')         AS version,   -- 16.0.4265.3
       SERVERPROPERTY('ProductLevel')           AS niveau,    -- RTM
       SERVERPROPERTY('ProductUpdateLevel')     AS cu,        -- CU26
       SERVERPROPERTY('ProductUpdateReference') AS kb,        -- KB5093420
       SERVERPROPERTY('Edition')                AS edition;

ProductLevel reste à RTM sur une instance à jour : il indique le Service Pack, et il n’y en a plus. Le niveau de CU se lit dans ProductUpdateLevel, qui vaut NULL tant qu’aucune CU n’est installée.

Le troisième groupe de chiffres de la build indique la branche. Sa valeur dépend de la version :

Pour 2019, 2022 et 2025, un troisième groupe en 4xxx signifie que des CU ont été appliquées. SQL Server 2017 fait exception, avec des CU en 3xxx. Lisez donc la build par rapport au RTM de sa version.

Installer la build la plus élevée de sa branche

Quand un correctif de sécurité sort après une CU, Microsoft publie le même jour une build pour chaque branche. Voici ce qui était disponible pour SQL Server 2019 le 14 juin 2022 :

Un administrateur qui cherchait « la dernière CU » le lendemain installait la CU16 et restait sans le correctif de juin. D’après la documentation Microsoft, une CU dont le numéro de build est supérieur à celui d’un CU + GDR contient ses correctifs de sécurité. La règle pratique est d’installer la build la plus élevée publiée pour votre branche, quel que soit son nom.

Limites du numéro de CU

SQL Server 2019 a reçu sa dernière CU, la CU32, le 27 février 2025. La branche CU continue de recevoir la sécurité, sous le même nom :

Deux instances qui affichent CU32 dans ProductUpdateLevel peuvent avoir un an et demi de correctifs de sécurité d’écart. Comparez le numéro de build complet.

Retrait d’une CU

La CU7 de SQL Server 2019 (15.0.4063.15, 2 septembre 2020) figure avec la mention « Removed » dans la liste des builds de SQL Server 2019. C’est rare, mais cela justifie d’attendre quelques jours à quelques semaines avant d’installer une CU en production, et de la passer d’abord sur une préproduction.

Trouver la bonne build

La méthode :

1. Relevez la build de l’instance avec la requête précédente.
2. Ouvrez la liste des builds de sa version, et trouvez la ligne de cette build.
3. Remontez à la build la plus récente de la même branche.
4. Suivez le lien KB, qui mène à la page de téléchargement.

Le site communautaire n’est pas une publication Microsoft (et il est très chargé en publicité de nos jours). Vérifiez la build et le KB sur Microsoft Learn avant de télécharger.

Les canaux de distribution

Les mises à jour SQL Server ne sont proposées par Windows Update qu’après adhésion à Microsoft Update, qui couvre les produits Microsoft autres que Windows. Sur Windows Server 2019 et suivants, le réglage est dans Paramètres > Windows Update > Options avancées > Recevoir les mises à jour pour d’autres produits Microsoft. Sans lui, un serveur à jour côté Windows n’a jamais reçu de correctif SQL Server.

Une mise à jour reçue par Microsoft Update s’installe sans surveillance, met à jour tous les composants SQL Server et redémarre le service. Sur un serveur de production, activez Microsoft Update pour être prévenu, et choisissez vous-même le moment de l’installation : la stratégie de groupe Configure Automatic Updates, option Auto download and notify for install, télécharge sans installer.

Instance neuve et Microsoft Update

Le canal automatique de Microsoft Update ne propose la version CU + GDR d’un correctif de sécurité qu’aux instances qui ont déjà une CU. Une instance restée au RTM reçoit la version GDR, et passe sur la branche GDR sans que personne l’ait décidé. WSUS ne la ramènera pas sur la branche CU : il faudra le faire à la main. Le détail est dans Updates to the Microsoft Update detection logic for SQL Server servicing.

Installez donc la dernière build de la branche CU juste après l’installation de SQL Server, avant d’activer Microsoft Update.

Appliquer une mise à jour sur une instance autonome

Avant

1. Faites une sauvegarde complète de toutes les bases, bases système comprises, vers un autre emplacement que le serveur. Un instantané de machine virtuelle ne remplace pas une sauvegarde SQL Server.
2. Lancez DBCC CHECKDB sur toutes les bases.
3. Lisez la page KB de la mise à jour, en particulier la section des problèmes connus.
4. Prévenez les utilisateurs et suspendez les travaux de l’Agent SQL Server.
5. Vérifiez l’espace disque : le paquet pèse de l’ordre de 500 Mo à 1 Go, et l’installateur a besoin de place pour ses fichiers temporaires.
6. Notez la build de départ.

Pendant

Exécutez le paquet en tant qu’administrateur. Un paquet CU contient les mises à jour de tous les composants de la version, mais ne met à jour que ceux qui sont installés. Si vous ajoutez un composant plus tard, Analysis Services par exemple, réappliquez la CU.

L’instance est indisponible pendant l’opération. Comptez une vingtaine de minutes sur une instance simple, redémarrage compris. Redémarrez le serveur si l’installateur le demande.

Après

-- La build doit correspondre à celle de la page KB
SELECT SERVERPROPERTY('ProductVersion') AS version,
       SERVERPROPERTY('ProductUpdateLevel') AS cu;

-- Bases qui ne sont pas en ligne
SELECT name, state_desc
FROM sys.databases
WHERE state_desc <> 'ONLINE';

-- Compte rendu des scripts de mise à niveau dans le journal d'erreurs
EXEC sys.xp_readerrorlog 0, 1, N'upgrade';

Réactivez ensuite les travaux de l’Agent et contrôlez un traitement réel de l’application.

Le redémarrage du service a des effets à connaître :

En cas de problème

Une CU se désinstalle depuis Panneau de configuration > Programmes et fonctionnalités > Afficher les mises à jour installées, sous l’entrée de la version de SQL Server. L’instance revient à la build précédente. Sur Linux, il faut revenir à la version précédente du paquet mssql-server. La sauvegarde prise avant l’intervention reste le recours si la désinstallation ne suffit pas.

Mettre à jour un groupe de disponibilité Always On

Sur un groupe de disponibilité, la mise à jour se fait réplica par réplica, avec un seul basculement manuel. Microsoft décrit la procédure dans Upgrade availability group replicas :

1. Sauvegardez chaque base du groupe et lancez DBCC CHECKDB.
2. Réglez la préférence de sauvegarde automatisée sur le réplica principal seul, et retirez le basculement automatique des réplicas synchrones.
3. Mettez à jour les réplicas secondaires asynchrones, puis les secondaires synchrones distants, puis les secondaires synchrones locaux.
4. Vérifiez que le secondaire cible est SYNCHRONIZED, puis basculez manuellement vers lui.
5. Mettez à jour l’ancien réplica principal.
6. Rétablissez le basculement automatique et, si vous le souhaitez, rebasculez vers le réplica principal d’origine.

# Nœud propriétaire des ressources principales du cluster
Get-ClusterGroup -Name "Cluster Group"

# Déplacement sur le nœud qui héberge le réplica principal
Move-ClusterGroup -Name "Cluster Group" -Node NOEUD-PRINCIPAL

Ne mettez jamais à jour le réplica principal en premier. Un réplica principal mis à jour ne peut plus envoyer son journal de transactions aux secondaires restés dans une version antérieure : la synchronisation s’arrête, et les bases sont exposées à une perte de données.

-- État de synchronisation de chaque base, par réplica
SELECT ag.name AS groupe,
       ar.replica_server_name AS replica,
       DB_NAME(drs.database_id) AS base,
       drs.synchronization_state_desc AS etat
FROM sys.dm_hadr_database_replica_states AS drs
JOIN sys.availability_replicas AS ar ON ar.replica_id = drs.replica_id
JOIN sys.availability_groups AS ag ON ag.group_id = drs.group_id
ORDER BY groupe, replica, base;

Rythme de vérification

Pour un serveur sans exigence particulière, une vérification par trimestre suffit :

1. Relevez la build installée.
2. Comparez-la à la build la plus élevée publiée pour sa branche.
3. Si l’écart dépasse deux CU, planifiez une fenêtre de maintenance.

Un GDR qui corrige une vulnérabilité exploitable à distance n’attend pas le trimestre. La page KB de chaque GDR renvoie vers la CVE correspondante, qui permet d’en juger.

À faire

1. Choisir la branche CU, sauf contrainte d’un éditeur.
2. Installer la build la plus élevée de la branche, CU + GDR compris.
3. Lire le numéro de build complet, et ProductUpdateLevel plutôt que ProductLevel.
4. Activer Microsoft Update ou WSUS, en choisissant le moment de l’installation.
5. Faire une sauvegarde et un DBCC CHECKDB avant chaque mise à jour.

À éviter

1. Chercher un Service Pack pour SQL Server 2017 ou une version plus récente.
2. Comparer des numéros de CU pour savoir quelle instance est la plus à jour.
3. Laisser une instance neuve au RTM avec Microsoft Update activé.
4. Installer en production une CU le jour de sa publication.
5. Mettre à jour le réplica principal d’un groupe de disponibilité avant ses secondaires.