Partager via

Mettre à niveau la copie des journaux de transaction vers SQL Server 2014 (Transact-SQL)

  • Article

Il est possible de conserver les configurations de copie des journaux de transaction lors de la mise à niveau de SQL Server 2005, SQL Server 2008, SQL Server 2008 R2 ou SQL Server 2012 vers SQL Server 2014. Cette rubrique décrit les scénarios et les méthodes conseillées pour la mise à niveau d'une configuration de la copie des journaux de transaction.

Notes

La compression de la sauvegarde a été introduite dans SQL Server 2008 Enterprise. Une configuration mise à niveau de copie des journaux de transaction utilise l’option de configuration du niveau serveur par défaut pour la compression de sauvegarde pour contrôler si la compression de la sauvegarde est utilisée pour les fichiers de sauvegarde du journal des transactions. Le comportement de la compression de la sauvegarde des sauvegardes de fichiers journaux peut être spécifié pour chaque configuration de la copie des journaux de transaction. Pour plus d’informations, consultez Configurer la copie des journaux de transaction (Transact-SQL).

Protéger vos données avant la mise à niveau

Comme méthode conseillée, nous vous recommandons de protéger vos données avant une mise à niveau de la copie des journaux de transaction.

Pour protéger vos données

  1. Effectuez une sauvegarde complète de chaque base de données primaire.

    Pour plus d’informations, consultez Créer une sauvegarde complète de base de données (SQL Server).

  2. Exécutez la commande DBCC CHECKDB sur chaque base de données primaire.

Mise à niveau d'une instance du serveur moniteur

L'instance du serveur moniteur, si elle existe, peut être mise à niveau à tout moment.

Pendant que le serveur moniteur est mis à niveau, la configuration de la copie des journaux de transaction continue à fonctionner, mais son état n'est pas enregistré dans les tables sur le moniteur. Les alertes qui ont été configurées ne sont pas déclenchées tant que le serveur moniteur est en cours de mise à niveau. Après la mise à niveau, vous pouvez mettre à jour les informations dans les tables du moniteur en exécutant la procédure stockée système sp_refresh_log_shipping_monitor.

Mise à niveau des configurations de copie des journaux de transaction avec un seul serveur secondaire

Le processus de mise à niveau décrit dans cette section présume une configuration composée du serveur principal et d'un seul serveur secondaire. La figure ci-après illustre cette configuration, avec une instance du serveur principal, A, et une seule instance du serveur secondaire, B.

Un serveur secondaire et aucun serveur d’analyse

Pour plus d'informations sur la mise à niveau de plusieurs serveurs secondaires, consultez Mise à niveau de plusieurs instances du serveur secondaire, plus loin dans cette rubrique.

Mise à niveau de l'instance du serveur secondaire

Le processus de mise à niveau implique la mise à niveau des instances de serveur secondaire d’une configuration de copie des journaux de transaction SQL Server 2005 ou ultérieure vers SQL Server 2014 avant de mettre à niveau le serveur principal instance. Mettez toujours à niveau l'instance du serveur secondaire en premier. Si le serveur principal était mis à niveau avant un serveur secondaire, la copie des journaux de transaction échouerait, car une sauvegarde créée sur une version plus récente de SQL Server ne peut pas être restaurée sur une version antérieure de SQL Server.

La copie des journaux de transaction se poursuit tout au long du processus de mise à niveau, car les serveurs secondaires mis à niveau continuent de restaurer les sauvegardes de journaux à partir du serveur principal SQL Server 2005 ou version ultérieure. Le processus de mise à niveau des instances de serveur secondaire dépend en partie du fait que la configuration de la copie des journaux de transaction possède ou non plusieurs serveurs secondaires. Pour plus d'informations, consultez Mise à niveau de plusieurs instances du serveur secondaire, plus loin dans cette rubrique.

Pendant que l'instance de serveur secondaire est mise à niveau, les travaux de copie et de restauration de la copie des journaux de transaction ne s'exécutent pas, de telle sorte que les sauvegardes des journaux des transactions non restaurées s'accumulent. La quantité accumulée dépend de la fréquence de la sauvegarde planifiée sur le serveur principal. De même, si un serveur moniteur séparé a été configuré, il se peut que des alertes soient déclenchées et indiquent que les restaurations n'ont pas été effectuées sur une durée supérieure à l'intervalle configuré.

Une fois que le serveur secondaire a été mis à niveau, les travaux des agents de la copie des journaux de transaction reprennent et poursuivent la copie et la restauration des sauvegardes de journaux à partir de l'instance du serveur principal, le serveur A. La durée requise pour que le serveur secondaire mette la base de données secondaire à jour varie, selon le temps nécessaire pour mettre à niveau le serveur secondaire et la fréquence des sauvegardes sur le serveur principal.

Notes

Pendant la mise à niveau du serveur, la base de données secondaire n’est pas mise à niveau vers une base de données SQL Server 2014. Elle ne sera mise à niveau que si elle est placée en ligne.

Important

L'option RESTORE WITH STANDBY n'est pas prise en charge pour une base de données qui requiert une mise à niveau. Si une base de données secondaire mise à niveau a été configurée à l'aide de RESTORE WITH STANDBY, les journaux des transactions ne peuvent plus être restaurés après la mise à niveau. Pour reprendre la copie des journaux de transaction sur cette base de données secondaire, vous devrez reconfigurer la copie des journaux de transaction sur ce serveur de secours. Pour plus d’informations sur l’option STANDBY, consultez ARGUMENTS RESTORE (Transact-SQL).

Mise à niveau de l'instance du serveur principal

Lors de la planification d'une mise à niveau, un élément important à prendre en compte est la durée pendant laquelle votre base de données ne sera pas disponible. Le scénario de mise à niveau le plus simple est que la base de données ne soit pas disponible pendant que vous mettez à niveau le serveur principal (scénario 1, ci-après).

Au prix d’un processus de mise à niveau plus complexe, vous pouvez optimiser la disponibilité de votre base de données en basculant le serveur principal SQL Server 2005 ou version ultérieure vers un serveur secondaire SQL Server 2014 avant de mettre à niveau le serveur principal d’origine (scénario 2, ci-dessous). Il existe deux variantes du scénario de basculement : vous pouvez revenir au serveur principal d'origine et sauvegarder la configuration de la copie des journaux de transaction originale. Autre solution, vous pouvez supprimer la configuration de la copie des journaux de transaction originale avant de mettre à niveau le serveur principal d'origine, puis, ultérieurement, créer une configuration à l'aide du nouveau serveur principal. Cette section décrit ces deux scénarios.

Important

Veillez à mettre à niveau l'instance du serveur secondaire avant l'instance du serveur principal. Pour plus d'informations, consultez Mise à niveau de l'instance du serveur secondaire, plus haut dans cette rubrique.

Scénario 1 : mettre à niveau l'instance de serveur principal sans basculement

C'est le scénario plus simple, mais il se traduit par un temps mort plus important que le basculement. L'instance de serveur principal est simplement mise à niveau et la base de données n'est pas disponible pendant cette mise à niveau.

Une fois que le serveur est mis à niveau, la base de données est automatiquement remise en ligne, ce qui entraîne sa mise à niveau. Après que la base de données a été mise à niveau, les travaux de la copie des journaux de transaction reprennent.

Scénario 2 : mettre à niveau l'instance de serveur principal avec basculement

Ce scénario optimise la disponibilité et réduit le temps mort. Il utilise un basculement contrôlé vers l'instance de serveur secondaire, ce qui maintient la base de données disponible pendant que vous mettez à niveau l'instance de serveur principal d'origine. Le temps mort est limité à la période de temps relativement courte nécessaire au basculement, et non à la durée requise pour mettre à niveau l'instance de serveur principal.

La mise à niveau du serveur principal instance avec basculement implique trois procédures générales : effectuer un basculement contrôlé vers le serveur secondaire, mettre à niveau le serveur principal d’origine instance vers SQL Server 2014 et configurer la copie des journaux de transaction sur un serveur principal SQL Server 2014 instance. Ces procédures sont décrites dans la présente section.

Important

Si vous prévoyez d'avoir l'instance de serveur secondaire comme nouvelle instance de serveur principal, vous devez supprimer la configuration de la copie des journaux de transaction. La copie des journaux de transaction doit être reconfigurée à partir du nouveau serveur principal vers le nouveau serveur secondaire, une fois que l'instance de serveur principal d'origine a été mise à niveau. Pour plus d’informations, consultez Supprimer la copie des journaux de transaction (SQL Server).

Procédure 1 : effectuer un basculement contrôlé vers le serveur secondaire

Basculement contrôlé vers le serveur secondaire :

  1. Exécutez manuellement une sauvegarde de la fin du journal du journal des transactions sur la base de données primaire en spécifiant WITH NORECOVERY. Cette sauvegarde capture les enregistrements de journal qui n'ont pas encore été sauvegardés et place la base de données hors connexion. Notez que pendant que la base de données est hors connexion, le travail de sauvegarde de la copie des journaux de transaction échoue.

    L'exemple suivant crée une sauvegarde de la fin du journal de la base de données AdventureWorks du serveur principal. Le fichier de sauvegarde est intitulé Failover_AW_20080315.trn:

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Failover_AW_20080315.trn' 
   WITH NORECOVERY;
GO

    Nous vous recommandons d'utiliser une convention d'affectation des noms de fichier distincte afin de différencier le fichier de sauvegarde créé manuellement des fichiers de sauvegarde créés par le travail de sauvegarde de la copie des journaux de transaction.

  2. Sur le serveur secondaire :

    1. Assurez-vous que toutes les sauvegardes effectuées automatiquement par les travaux de sauvegarde de la copie des journaux de transaction ont été appliquées. Pour case activée les travaux de sauvegarde qui ont été appliqués, utilisez la procédure stockée système sp_help_log_shipping_monitor sur le serveur de surveillance ou sur les serveurs principaux et secondaires. Le même fichier doit apparaître dans les colonnes last_backup_file, last_copied_fileet last_restored_file . Si l'un des fichiers de sauvegarde n'a pas été copié et restauré, appelez manuellement les travaux de copie et de restauration de l'agent pour la configuration de la copie des journaux de transaction.

      Pour plus d'informations sur le démarrage d'un travail, consultez Start a Job.

    2. Copiez le dernier fichier de sauvegarde de journal créé dans l'étape 1 à partir du partage de fichiers vers l'emplacement local utilisé par la copie des journaux de transaction sur le serveur secondaire.

    3. Restaurez la dernière sauvegarde de fichier journal en spécifiant WITH RECOVERY pour mettre la base de données en ligne. Dans le cadre de sa mise en ligne, la base de données sera mise à niveau vers SQL Server 2014.

      L'exemple suivant restaure sauvegarde de la fin du journal de la base de données AdventureWorks sur la base de données secondaire. L'exemple utilise l'option WITH RECOVERY, qui place la base de données en ligne :

      RESTORE LOG AdventureWorks 
  FROM DISK = N'c:\logshipping\Failover_AW_20080315.trn' 
   WITH RECOVERY;
GO

      Notes

      Pour une configuration qui contient plusieurs serveurs secondaires, certains éléments supplémentaires sont à prendre en compte. Pour plus d'informations, consultez Mise à niveau de plusieurs instances du serveur secondaire, plus loin dans cette rubrique.

    4. Basculez la base de données en redirigeant les clients depuis le serveur principal original (serveur A) vers le serveur secondaire en ligne (serveur B).

    5. Veillez à ce que le journal des transactions de la base de données secondaire ne se remplisse pas pendant que la base de données est en ligne. Pour empêcher le journal des transactions de se remplir, vous pouvez avoir besoin de le sauvegarder. Si tel est le cas, nous vous recommandons de le sauvegarder dans un emplacement partagé, un partage de sauvegarde, pour que les sauvegardes soient disponibles pour être restaurées sur l'autre instance de serveur.

Procédure 2 : Mettre à niveau l’instance de serveur principal d’origine vers SQL Server 2014

Une fois que vous avez mis à niveau le serveur principal d’origine instance vers SQL Server 2014, la base de données reste hors connexion et au format .

Procédure 3 : Configurer la copie des journaux de transaction le SQL Server 2014

Le reste du processus de mise à niveau dépend du fait que la copie des journaux de transaction est toujours configurée ou pas, comme suit :

Pour revenir à l'instance du serveur principal d'origine

  1. Sur le serveur principal temporaire (serveur B), sauvegardez la fin du journal avec l'option WITH NORECOVERY pour créer une sauvegarde de la fin du journal et placer la base de données hors connexion. La sauvegarde de la fin du journal s'intitule Switchback_AW_20080315.trn. Par exemple :

    BACKUP LOG AdventureWorks 
  TO DISK = N'\\FileServer\LogShipping\AdventureWorks\Switchback_AW_20080315.trn' 
   WITH NORECOVERY;
GO

  2. Si les sauvegardes des journaux des transactions ont eu lieu sur la base de données primaire temporaire, autres que la sauvegarde de fin créée à l'étape 1, restaurez ces sauvegardes de journaux à l'aide de WITH NORECOVERY sur la base de données hors connexion du serveur principal d'origine (serveur A). La base de données est mise à niveau vers SQL Server format 2014 lorsque la première sauvegarde du journal est restaurée.

  3. Restaurez la sauvegarde de la fin du journal, Switchback_AW_20080315.trn, sur la base de données primaire d'origine (sur le serveur A) à l'aide de l'option WITH RECOVERY pour mettre la base de données en ligne.

  4. Basculez à nouveau vers la base de données primaire d'origine (sur le serveur A) en redirigeant les clients vers le serveur secondaire en ligne à partir du serveur principal d'origine.

Après que la base de données a été placée en ligne, la configuration de la copie des journaux de transaction d'origine se poursuit.

Pour conserver l'ancienne instance du serveur secondaire comme nouvelle instance du serveur principal

Établissez une nouvelle configuration de la copie des journaux de transaction en utilisant l'ancienne instance de serveur secondaire, B, comme serveur principal et l'ancienne instance de serveur principal, A, comme nouveau serveur secondaire :

Important

L'ancienne configuration de la copie des journaux de transaction doit avoir été supprimée du serveur principal d'origine au démarrage du processus avant d'effectuer la sauvegarde manuelle des journaux des transactions qui a placé la base de données hors connexion.

  1. Pour éviter d'effectuer une sauvegarde et une restauration complètes de la base de données sur le nouveau serveur secondaire (serveur A), appliquez les sauvegardes de journaux de la nouvelle base de données primaire vers la nouvelle base de données secondaire. Dans l'exemple de configuration, cela nécessite de restaurer les sauvegardes de journaux effectuées sur le serveur B vers la base de données du serveur A.

  2. Sauvegardez le journal à partir de la nouvelle base de données primaire (serveur B).

  3. Restaurez les sauvegardes des journaux vers la nouvelle instance de serveur secondaire (serveur A) à l'aide de WITH NORECOVERY. La première opération de restauration met à jour la base de données vers SQL Server 2014.

  4. Configurez la copie des journaux de transaction avec le précédent serveur secondaire (serveur B) comme instance de serveur principal.

    Important

    Si vous utilisez SQL Server Management Studio, spécifiez que la base de données secondaire est déjà initialisée.

    Pour plus d’informations, consultez Configurer la copie des journaux de transaction (Transact-SQL).

  5. Basculez la base de données en redirigeant les clients depuis le serveur principal original (serveur A) vers le serveur secondaire en ligne (serveur B).

    Important

    Lorsque vous basculez vers une nouvelle base de données primaire, vous devez vous assurer que ses métadonnées sont cohérentes avec celles de la base de données principale d'origine. Pour plus d’informations, consultez Gérer les métadonnées durant la mise à disposition d’une base de données sur une autre instance de serveur (SQL Server).

Mise à niveau de plusieurs instances du serveur secondaire

La figure ci-après illustre cette configuration, avec une instance du serveur principal, A, et deux instances du serveur secondaire, B et C.

Deux serveurs secondaires et aucun serveur de surveillance

Cette section traite de la procédure de mise à niveau avec basculement et du retour au serveur principal d'origine Lors de la mise à niveau de l'instance principale avec le basculement, le processus est plus complexe quand il y a plusieurs instances de serveur secondaire. Dans la procédure suivante, après que tous les serveurs secondaires ont été mis à niveau, le serveur principal est basculé vers l'une des bases de données secondaires mises à niveau. Le serveur principal d'origine est mis à niveau et la copie des journaux de transaction est basculée vers ce serveur.

Important

Mettez toujours à niveau toutes les instances de serveur secondaires avant de mettre à niveau le serveur principal.

Pour effectuer une mise à niveau avec basculement et retourner au serveur principal d'origine

  1. Mettez à niveau toutes les instances de serveur secondaire (serveur B et serveur C).

  2. Récupérez la fin du journal des transactions de la base de données primaire (sur le serveur A) et placez la base de données hors connexion, en sauvegardant le journal des transactions avec l'option WITH NORECOVERY.

  3. Sur le serveur secondaire vers lequel vous prévoyez de basculer (serveur B), mettez la base de données secondaire en ligne, en restaurant la sauvegarde du journal à l'aide de WITH RECOVERY.

  4. Sur chaque autre serveur secondaire (serveur C), laissez la base de données secondaire hors ligne en restaurant la sauvegarde de journal à l'aide de WITH NORECOVERY.

    Notes

    Les travaux de copie et de restauration de la copie des journaux de transaction s'exécutent sur les serveurs secondaires, mais les travaux demeurent inactifs parce que les nouveaux fichiers de sauvegarde des journaux ne sont pas placés sur le partage de sauvegarde.

  5. Basculez la base de données en redirigeant les clients depuis le serveur principal original (serveur A) vers le serveur secondaire en ligne (serveur B). La base de données en ligne devient un serveur principal temporaire, en conservant la base de données disponible pendant que le serveur principal d'origine est hors connexion (serveur A).

  6. Mettez à niveau le serveur principal d'origine (serveur A).

  7. Sur la base de données vers laquelle vous avez basculé la base de données primaire intermédiaire (sur le serveur B), sauvegardez manuellement le journal des transactions à l’aide de WITH NORECOVERY. La base de données est alors placée hors connexion.

  8. Restaurez toutes les sauvegardes des journaux des transactions que vous avez créées sur la base de données primaire temporaire (sur le serveur B) sur chaque autre base de données secondaire (sur le serveur C) à l'aide de WITH NORECOVERY. Cela permet à la copie des journaux de transaction de se poursuivre depuis la base de données primaire d'origine après sa mise à niveau, sans nécessiter une restauration de base de données complète sur chaque base de données secondaire.

  9. Restaurez le journal des transactions depuis le serveur principal temporaire (serveur B) vers la base de données primaire d'origine (sur le serveur A) à l'aide de l'option WITH RECOVERY.

Redéploiement de la copie des journaux de transaction

Si vous ne souhaitez pas migrer la configuration de la copie des journaux de transaction à l'aide de l'une des procédures indiquées ci-dessus, vous pouvez redéployer entièrement la copie des journaux de transaction en réinitialisant la base de données secondaire avec une sauvegarde et une restauration complètes de la base de données primaire. Cette option peut être souhaitable si vous avez une base de données peu volumineuse ou si une haute disponibilité n'est pas primordiale pendant la mise à niveau.

Pour plus d’informations sur l’activation de la copie des journaux de transaction, consultez Configurer la copie des journaux de transaction (SQL Server).

Voir aussi

Sauvegardes du journal des transactions (SQL Server)Appliquer les sauvegardes du journal des transactions (SQL Server)Tables de copie des journaux de transaction et procédures stockées