Choisir une méthode de mise à niveau du moteur de base de données
S’applique à : SQL Server - Windows uniquement
Si vous planifiez une mise à niveau du Moteur de base de données à partir d’une version antérieure de SQL Server, plusieurs approches sont possibles pour réduire les temps d’arrêt du service et les risques. Vous pouvez effectuer une mise à niveau sur place, une migration vers une nouvelle installation ou une mise à niveau propagée. Le diagramme suivant vous aidera à choisir l’approche appropriée. Chaque approche présentée sur le diagramme est également décrite ci-dessous. Pour vous aider avec les points de décision du diagramme, passez également en revue Planifier et tester le plan de mise à niveau du moteur de base de données.
Télécharger
Pour télécharger SQL Server, consultez le Centre d’évaluation.
Vous avez un compte Azure ? Accédez ensuite à la Place de marché Azure pour lancer une machine virtuelle avec SQL Server Developer Edition déjà installé.
Options de mise à niveau d’Azure SQL
Vous pouvez également envisager de mettre à niveau la Base de données SQL Azure ou de virtualiser votre environnement SQL Server dans le cadre de votre plan de mise à niveau. Pour plus d’informations sur ces options, consultez les rubriques suivantes :
- Vue d’ensemble de SQL Server sur les machines virtuelles Azure
- Azure SQL Database
- Sélection d’une option SQL Server dans Azure
Mettre à niveau sur place
Avec cette approche, le programme d’installation de SQL Server met à niveau l’installation SQL Server existante en remplaçant SQL Server par le nouveau SQL Server, puis met à niveau les bases de données système et utilisateur.
La mise à niveau sur place est l’approche la plus simple. Toutefois, elle implique un certain temps d’arrêt, le rétablissement de secours dure plus longtemps le cas échéant et cette procédure n’est pas prise en charge dans tous les scénarios. Pour plus d’informations sur les scénarios de mise à niveau sur place pris en charge et non pris en charge, consultez Mises à niveau de la version et de l’édition prises en charge.
Cette approche est souvent utilisée dans les cas suivants :
Environnement de développement sans configuration à haute disponibilité.
Environnement de production non stratégique pouvant tolérer un temps mort et s’exécutant sur du matériel des logiciels récents. La durée du temps d’arrêt dépend de la taille de votre base de données et de la vitesse de votre sous-système d’E/S. Une mise à niveau de SQL Server 2014 (12.x) quand les tables à mémoire optimisée sont en cours d’utilisation prend plus de temps. Pour plus d’informations, consultez Planifier et tester le plan de mise à niveau du moteur de base de données.
À un niveau élevé, les étapes requises pour une mise à niveau sur place du Moteur de base de données sont les suivantes :
Pour obtenir des instructions détaillées, consultez Mettre à niveau SQL Server en utilisant l’Assistant Installation (Configuration).
À propos de l’installation
Le programme d’installation de SQL Server arrête et redémarre l’instance SQL Server dans le cadre des vérifications de pré-mise à niveau.
Lorsque vous effectuerez une mise à niveau vers SQL Server, l’instance SQL Server précédente sera remplacée et n’existera plus sur votre ordinateur. Avant d'opérer la mise à niveau, sauvegardez les bases de données SQL Server et les autres objets associés à l'instance SQL Server précédente.
Migrer vers une nouvelle installation
Avec cette approche, vous conservez l’environnement actuel tout en construisant un nouvel environnement SQL Server , souvent sur un nouveau matériel et avec une nouvelle version du système d’exploitation. Après l’installation de SQL Server dans le nouvel environnement, vous effectuez plusieurs étapes pour préparer le nouvel environnement pour pouvoir migrer les bases de données utilisateur de l’environnement existant vers le nouveau, tout en réduisant le temps d’arrêt. Ces étapes comprennent la migration des éléments suivants :
Objets système : Certaines applications dépendent d'informations, d'entités et/ou d'objets qui n'appartiennent pas au champ d'action d'une base de données mono-utilisateur. Généralement, une application possède des dépendances sur les bases de données
master
etmsdb
, ainsi que la base de données utilisateur. Les informations stockées en dehors d'une base de données utilisateur et nécessaires au bon fonctionnement de cette base de données doivent être disponibles sur l'instance du serveur de destination. Par exemple, les connexions pour une application sont stockées en tant que métadonnées dans la base de donnéesmaster
, et doivent être recréées sur le serveur de destination. Si un plan de maintenance d’application ou de base de données dépend des travaux SQL Server Agent dont les métadonnées sont stockées dans la base de donnéesmsdb
, vous devez recréer ces travaux sur l’instance du serveur de destination. De la même façon, les métadonnées d’un déclencheur de niveau serveur sont stockées dans la base de donnéesmaster
.Quand vous déplacez la base de données d’une application vers une autre instance de serveur, vous devez recréer toutes les métadonnées des entités et des objets dépendants dans les bases de données
master
etmsdb
sur l’instance du serveur de destination. Par exemple, si une application de base de données utilise des déclencheurs au niveau serveur, il ne suffit pas d’attacher ni de restaurer la base de données sur le nouveau système. La base de données ne fonctionne pas comme prévu, sauf si vous recréez manuellement les métadonnées pour ces déclencheurs dans la base de donnéesmaster
. Pour plus d’informations, consultez Gérer les métadonnées pour rendre une base de données disponible sur une autre instance de serveur (SQL Server)Packages de services d’intégration stockés dans
msdb
: si vous stockez des packages dansmsdb
, vous devez soit écrire ces packages dans un script à l’aide de dtutil Utility, soit les redéployer sur le nouveau serveur. Avant d’utiliser les packages sur le nouveau serveur, vous devez mettre à niveau les packages vers SQL Server. Pour plus d’informations, voir Upgrade Integration Services Packages.Clés de chiffrement Reporting Services : Une part importante de la configuration d'un serveur de rapports est réservée à la création d'une copie de sauvegarde de la clé symétrique utilisée pour le chiffrement d'informations confidentielles. Cet exemplaire de clé sauvegardée est nécessaire dans de nombreuses opérations courantes. Elle vous permet de réutiliser une base de données de serveur de rapports existante dans une nouvelle installation. Pour plus d’informations, consultez Sauvegarder et restaurer les clés de chiffrement Reporting Services et Mettre à niveau et faire migrer Reporting Services
Une fois que le nouvel environnement SQL Server a les mêmes objets système que l’environnement existant, vous migrez les bases de données utilisateur du système existant vers l’instance SQL Server de façon à réduire les temps d’arrêt sur le système existant. Vous effectuez la migration de base de données à l’aide d’une sauvegarde et restauration, ou en repointant les LUN si vous êtes dans un environnement SAN. Les étapes des deux méthodes sont présentées dans les diagrammes suivants.
Attention
La durée du temps d’arrêt dépend de la taille de votre base de données et de la vitesse de votre sous-système d’E/S. Une mise à niveau de SQL Server 2014 (12.x) quand les tables à mémoire optimisée sont en cours d’utilisation prendra plus de temps. Pour plus d’informations, consultez Planifier et tester le plan de mise à niveau du moteur de base de données.
Après la migration des bases de données utilisateur, vous pointez les nouveaux utilisateurs sur la nouvelle instance SQL Server en utilisant l’une des méthodes (par exemple renommer le serveur, utiliser une entrée DNS, modifier des chaînes de connexion). La nouvelle approche d’installation réduit les risques et les temps d’arrêt par rapport à une mise à niveau sur place. Elle facilite également les mises à niveau du matériel et du système d’exploitation conjointement à la mise à niveau vers SQL Server.
Remarque
Si vous avez déjà une solution à haute disponibilité en place ou d’autres environnements d’instance SQL Server, accédez à Mise à niveau propagée. Si vous n’avez pas de solution de haute disponibilité en place, vous pouvez configurer temporairement une mise en miroir de bases de données pour réduire le temps d’arrêt pour faciliter cette mise à niveau, ou en profiter pour configurer un groupe de disponibilité Always On comme solution HA permanente.
Par exemple, vous pouvez utiliser cette approche pour mettre à niveau :
- Une installation de SQL Server sur un système d’exploitation non pris en charge.
- Une installation x86 (32 bits) de SQL Server en tant que SQL Server 2016 (13.x) et versions ultérieures ne prend pas en charge les installations x86.
- SQL Server vers un nouveau matériel ou une nouvelle version du système d’exploitation.
- SQL Server avec la consolidation des serveurs.
- SQL Server 2005 (9.x), comme SQL Server 2016 (13.x) et les versions ultérieures ne prennent pas en charge la mise à niveau en place de SQL Server 2005 (9.x). Pour plus d’informations, consultez Mise à niveau d’une version antérieure de SQL Server.
Les étapes requises pour une nouvelle mise à niveau d’installation varient légèrement selon que vous utilisez un stockage SAN ou un stockage connecté.
Environnement de stockage connecté : Si vous avez un environnement SQL Server utilisant un stockage connecté, le diagramme suivant et les liens qu’il contient vous guident dans les étapes nécessaires à la mise à niveau de la nouvelle installation vers Moteur de base de données.
Environnement de stockage SAN : si vous avez un environnement SQL Server utilisant un stockage SAN, le diagramme suivant et les liens qu’il contient vous guident dans les étapes nécessaires pour mettre à niveau une nouvelle installation du moteur de base de données.
Mise à niveau propagée
Une mise à niveau propagée est requise dans les environnements de solution SQL Server impliquant plusieurs instances SQL Server qui doivent être mises à niveau dans un certain ordre afin d’optimiser le temps de fonctionnement, de minimiser les risques et de préserver la fonctionnalité. Une mise à niveau propagée consiste essentiellement en la mise à niveau de plusieurs instances SQL dans un ordre particulier. Vous effectuez une mise à niveau sur place sur chaque instance SQL existante ou une mise à niveau via une nouvelle installation pour faciliter la mise à niveau du matériel et/ou du système d’exploitation dans le cadre du projet de mise à niveau. Il existe plusieurs scénarios dans lesquels vous devez utiliser l’approche de mise à niveau propagée. Ces résultats sont décrits dans les articles suivants :
- Groupes de disponibilité : pour obtenir des instructions détaillées sur l’exécution d’une mise à niveau propagée dans cet environnement, consultez Mise à niveau d’instances de réplica d’un groupe de disponibilité Always On
- Instances de cluster de basculement : Pour obtenir des instructions détaillées sur l’exécution d’une mise à niveau propagée dans cet environnement, consultez Mise à niveau d’une instance de cluster de basculement SQL Server.
- Instances mises en miroir : pour obtenir des instructions détaillées sur l’exécution d’une mise à niveau propagée dans cet environnement, consultez Mise à niveau des instances en miroir.
- Instances de copie des journaux de transaction : pour obtenir des instructions détaillées sur l’exécution d’une mise à niveau propagée dans cet environnement, consultez Mise à niveau de la copie des journaux de transaction pour SQL Server (Transact-SQL)
- Environnement de réplication : pour obtenir des instructions détaillées pour effectuer une mise à niveau propagée dans cet environnement, voir Upgrade Replicated Databases.
- Environnement avec montée en puissance de SQL Server Reporting Services : pour obtenir des instructions détaillées sur l’exécution d’une mise à niveau propagée dans cet environnement, consultez Mettre à niveau et faire migrer Reporting Services.