Mettre à niveau la fonction de transfert de journaux vers SQL Server 2014 (Transact-SQL)

Il est possible de conserver les configurations de log shipping 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 différents scénarios alternatifs et les meilleures pratiques pour la mise à niveau d'une configuration d'expédition de journaux.

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 de l’instance du serveur Monitor

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 l'expédition des journaux avec un seul serveur secondaire

Le processus de mise à niveau décrit dans cette section suppose une configuration composée du serveur principal et d’un seul serveur secondaire. Cette configuration est représentée dans l’illustration suivante, qui montre une instance de serveur principal, A et une seule instance de serveur secondaire, B.

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

Mise à niveau de l’instance de 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 l’instance de serveur principal. Mettez toujours à niveau l’instance de serveur secondaire en premier. Si le serveur principal était mis à niveau avant un serveur secondaire, alors l'expédition des journaux é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.

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

Pendant la mise à niveau de l’instance de serveur secondaire, les travaux de copie et de restauration des journaux de transaction ne s’exécutent pas, de sorte que les sauvegardes des journaux de transactions non restaurées s’accumulent. La quantité d’accumulation dépend de la fréquence de 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 le serveur secondaire mis à niveau, les travaux des agents de journalisation reprennent et continuent de copier et de restaurer des journaux de l'instance du serveur principal, serveur A. La durée nécessaire au serveur secondaire pour mettre à jour la base de données secondaire varie en fonction du temps nécessaire à la mise à niveau du serveur secondaire et de la fréquence des sauvegardes sur le serveur principal.

Mise à niveau de l'instance du serveur principal

Lors de la planification d’une mise à niveau, une considération importante est la durée pendant laquelle votre base de données n’est pas disponible. Le scénario de mise à niveau le plus simple implique l’indisponibilité de la base de données pendant la mise à niveau du serveur principal (scénario 1, ci-dessous).

Au coût 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 supérieur 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 conserver la configuration d'expédition des journaux d'origine. Vous pouvez également supprimer la configuration d'expédition des journaux d'origine avant de mettre à niveau le serveur principal d'origine. Ensuite, créez une nouvelle configuration en utilisant le nouveau serveur principal. Cette section décrit ces deux scénarios.

Scénario 1 : Mettre à niveau l’instance de serveur principal sans basculement

Il s’agit d’un scénario plus simple, mais il provoque davantage de temps d'arrêt que l’utilisation du 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 les temps d’arrêt. Il utilise un basculement contrôlé vers l’instance de serveur secondaire, qui conserve la base de données disponible pendant la mise à niveau de l’instance de serveur principal d’origine. Les temps d’arrêt sont limités au temps de basculement relativement court, plutôt qu’au temps nécessaire pour mettre à niveau l’instance de serveur principal.

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

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

Basculement contrôlé vers le serveur secondaire :

1. Effectuez manuellement une sauvegarde de la fin du journal des transactions sur la base de données primaire en spécifiant WITH NORECOVERY. Cette sauvegarde de journal capture tous les enregistrements de journal qui n’ont pas encore été sauvegardés et met la base de données hors ligne. Notez que pendant que la base de données est hors connexion, la tâche de sauvegarde de la journalisation échouera.

   L’exemple suivant crée une sauvegarde du journal de queue de la base de données du serveur principal. Le fichier de sauvegarde est nommé 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 de nommage de fichiers distincte pour différencier le fichier de sauvegarde créé manuellement des fichiers de sauvegarde créés par la tâche de sauvegarde de transfert de journaux.

2. Sur le serveur secondaire :

   1. Vérifiez que toutes les sauvegardes effectuées automatiquement par les travaux de sauvegarde de copie des journaux de transaction ont été appliquées. Pour vérifier quels travaux de sauvegarde ont été appliqués, utilisez la procédure stockée système sp_help_log_shipping_monitor sur le serveur moniteur ou sur les serveurs principaux et secondaires. Le même fichier doit être répertorié dans les colonnes last_backup_file, last_copied_file et 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 copie des journaux de transaction.

      Pour plus d’informations sur le démarrage d’un travail, consultez Démarrer un travail.

   2. Copiez le fichier de sauvegarde de journal final que vous avez créé à 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 sauvegarde finale du journal spécifiant WITH RECOVERY pour mettre la base de données en ligne. Dans le cadre de la mise en ligne, la base de données sera mise à niveau vers SQL Server 2014.

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

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

      Remarque

      Pour une configuration qui contient plusieurs serveurs secondaires, il existe des considérations supplémentaires. Pour plus d’informations, consultez Mise à niveau de plusieurs instances de serveur secondaire, plus loin dans cette rubrique.

   4. Effectuez une bascule de la base de données en redirigeant les clients du serveur principal d’origine (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 remplissage du journal des transactions, vous devrez peut-être le sauvegarder. Si c’est le cas, nous vous recommandons de le sauvegarder à un emplacement partagé, un partage de sauvegarde, afin de rendre les sauvegardes disponibles pour la restauration sur l’autre instance de serveur.

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

Après avoir mis à niveau l’instance de serveur principal d’origine vers SQL Server 2014, la base de données est toujours hors connexion et au format.

Procédure 3 : Configurer la journalisation des transactions sur SQL Server 2014

Le reste du processus de mise à niveau dépend de la configuration de la copie des journaux de transaction, comme suit :

• Si vous avez conservé la configuration de copie des journaux de la base de données SQL Server 2005 ou supérieur, revenez à l'instance originale du serveur principal. Pour plus d’informations, consultez Pour revenir à l’instance de serveur principal d’origine, plus loin dans cette section.

• Si vous avez supprimé la configuration de copie des journaux de transaction avant de basculer, établissez une configuration de copie des journaux de transaction dans laquelle l’instance de serveur secondaire d’origine est la nouvelle instance de serveur principal. Pour plus d’informations, consultez Pour conserver l’ancienne instance de serveur secondaire en tant que nouvelle instance de serveur principal, plus loin dans cette section.

Pour revenir à l’instance de serveur principal d’origine

1. Sur le serveur principal intermédiaire (serveur B), sauvegardez la fin du journal à l’aide de WITH NORECOVERY pour créer une sauvegarde de la fin du journal et mettre la base de données hors connexion. La sauvegarde du journal de fin est nommée Switchback_AW_20080315.trn. Par exemple:

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

2. Si des sauvegardes de journal des transactions ont été effectuées sur la base de données primaire intermédiaire, autre que la sauvegarde de fin que vous avez créée à l’étape 1, restaurez ces sauvegardes de journaux à l’aide de WITH NORECOVERY sur la base de données hors connexion sur le serveur principal d’origine (serveur A). La base de données est mise à niveau vers le format SQL Server 2014 lorsque la première sauvegarde du journal est restaurée.

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

4. Basculez 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.

Une fois que la base de données est en ligne, la configuration originale de la copie des journaux de transaction reprendra.

Pour conserver l’ancienne instance de serveur secondaire comme nouvelle instance de serveur principal

Établissez une nouvelle configuration d'expédition des journaux en utilisant l'ancienne instance de serveur secondaire, B, en tant que serveur principal et l'ancienne instance de serveur principal, A, comme nouveau serveur secondaire, comme suit :

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 à la nouvelle base de données secondaire. Dans l’exemple de configuration, cela implique la restauration des sauvegardes de logs effectuées sur le serveur B vers la base de données sur le serveur A.

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

3. Restaurez les sauvegardes de journal sur 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 le "log shipping" avec l'ancien serveur secondaire (serveur B) comme nouvelle 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. Transférez la base de données en redirigeant les clients du serveur principal d’origine (serveur A) vers le serveur secondaire qui est opérationnel 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 les métadonnées de la base de données primaire 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 de serveur secondaire

Cette configuration est représentée dans l’illustration suivante, qui montre une instance de serveur principal, A et deux instances de serveur secondaire, B et C.

Cette section explique comment effectuer une mise à niveau à l’aide d’un basculement, puis revenir au serveur principal d’origine. Lors de la mise à niveau de l’instance principale avec basculement, le processus est plus complexe lorsqu’il existe plusieurs instances de serveur secondaire. Dans la procédure suivante, une fois tous les serveurs secondaires 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 à nouveau vers celui-ci.

Pour effectuer une mise à niveau à l’aide d’un basculement, puis revenir au serveur principal d’origine

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

2. Obtenez la fin du journal des transactions de la base de données primaire (sur le serveur A) et utilisent la base de données hors connexion en sauvegarde du journal des transactions à l’aide de WITH NORECOVERY.

3. Sur le serveur secondaire sur lequel vous envisagez 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 tous les autres serveurs secondaires (serveur C), laissez la base de données secondaire hors connexion en restaurant la sauvegarde du journal à l’aide de WITH NORECOVERY.

   Remarque

   Les travaux de copie et de restauration de copie des journaux de transaction s’exécutent sur les serveurs secondaires, mais les travaux ne font rien, car les nouveaux fichiers de sauvegarde ne seront pas placés sur le partage de sauvegarde.

5. Basculez la base de données en redirigeant les clients du serveur principal d’origine (serveur A) vers le serveur secondaire en ligne (serveur B). La base de données en ligne devient un serveur principal intermédiaire, gardant 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 temporairement principale (sur le serveur B) vers laquelle vous avez basculé, sauvegardez manuellement le journal des transactions en utilisant l'option WITH NORECOVERY. Cela met la base de données hors connexion.

8. Restaurez toutes les sauvegardes de journal des transactions que vous avez créées sur la base de données primaire intermédiaire (sur le serveur B) sur toutes les autres bases de données secondaires (sur le serveur C) à l’aide de WITH NORECOVERY. Cela permet à la copie des journaux de transaction de continuer à partir de la base de données primaire d’origine après sa mise à niveau, sans nécessiter de restauration complète de base de données sur chaque base de données secondaire.

9. Restaurez le journal des transactions du serveur principal intermédiaire (serveur B) vers la base de données primaire d’origine (sur le serveur A) à l’aide de WITH RECOVERY.

Redéploiement de la copie des journaux de transaction

Si vous ne souhaitez pas migrer votre configuration de copie des journaux de transaction à l’aide de l’une des procédures indiquées ci-dessus, vous pouvez redéployer la copie des journaux de transaction à partir de zéro en réinitialisant votre base de données secondaire avec une sauvegarde complète et une restauration de la base de données primaire. Il peut s’agir d’une option souhaitable si vous avez une petite base de données ou si la haute disponibilité n’est pas cruciale pendant la procédure de 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 des sauvegardes de journal des transactions (SQL Server)Tables de copie des journaux de transaction et procédures stockées