Choisir une méthode de mise à niveau du moteur de base de données

  • Article

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.

Schéma montrant l’arbre de décision de la méthode 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 :

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 :

Schéma montrant la mise à niveau sur place sans configuration à haute disponibilité du moteur de base de données.

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 et msdb, 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ées master, 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ées msdb, 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ées master.

    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 et msdb 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ées master. 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 dans msdb, 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.

    Schéma montrant une nouvelle méthode de mise à niveau d’installation qui utilise la sauvegarde et la restauration pour le stockage attaché.

  • 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.

    Schéma montrant une nouvelle méthode de mise à niveau d’installation utilisant le détachement et l’attachement pour le stockage SAN.

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 :