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

Il est possible de conserver les configurations de copie des journaux de transaction lors d'une mise à niveau de SQL Server 2005, SQL Server 2008 ou SQL Server 2008 R2 vers SQL Server 2012. 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.

[!REMARQUE]

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 backup compression default 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 (SQL Server).

Dans cette rubrique :

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

• Mise à niveau d'une instance du serveur moniteur

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

• Mise à niveau de plusieurs instances du serveur secondaire

• Redéploiement de la copie des journaux de transaction

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.

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.

Dans cette section :

• Mise à niveau de l'instance du serveur secondaire

• Mise à niveau de l'instance du serveur principal

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 SQL Server 2005, SQL Server 2008 ouSQL Server 2008 R2 de copie des journaux de transaction vers SQL Server 2012 avant la mise à niveau de l'instance du serveur principal. Mettez toujours à niveau l'instance du serveur secondaire en premier. Si le serveur principal a été mis à niveau avant un serveur secondaire, la copie des journaux de transaction échoue parce qu'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 durant le processus de mise à niveau parce que les serveurs secondaires mis à niveau continuent à restaurer les sauvegardes des journaux à partir du serveur principal SQL Server 2005, SQL Server 2008 ou SQL Server 2008 R2. 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 copie des journaux de transaction reprennent et poursuivent la copie et la restauration des sauvegardes de journal à partir de l'instance du serveur principal, le serveur A. La durée nécessaire pour que le serveur secondaire remette la base de données secondaire à jour varie, selon la durée requise pour mettre à niveau le serveur secondaire et la fréquence des sauvegardes sur le serveur principal.

[!REMARQUE]

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 2012. Elle ne sera mise à niveau que si elle est placée en ligne.

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 compliqué, vous pouvez augmenter la disponibilité de votre base de données en basculant le serveur principal SQL Server 2005, SQL Server 2008 ou SQL Server 2008 R2 vers un serveur secondaire SQL Server 2012 avant de mettre à niveau le serveur principal d'origine (scénario 2, ci-après). 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.

Dans cette section :

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

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

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 de l'instance de serveur principal avec le basculement implique trois procédures générales : exécuter un basculement contrôlé sur le serveur secondaire, mettre à niveau l'instance de serveur principal d'origine vers SQL Server 2012 et installer la copie des journaux de transaction sur une instance de serveur principal SQL Server 2012. Ces procédures sont décrites dans la présente section.

Dans cette section :

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

• Procédure 2 : Mettre à niveau l'instance de serveur principal d'origine vers SQL Server 2012

• Procédure 3 : installer la copie des journaux de transaction sur SQL Server 2012

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 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 principal et secondaires. Le même fichier doit apparaître 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 la copie des journaux de transaction.

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

   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 est mise à niveau vers SQL Server 2012.

      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
      

      [!REMARQUE]

      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 du serveur principal d'origine vers SQL Server 2012

Après avoir mis à niveau l'instance du serveur principal d'origine vers SQL Server 2012, la base de données demeure hors connexion et dans le format.

Procédure 3 : installer la copie des journaux de transaction sur SQL Server 2012

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 :

• Si vous avez conservé la configuration de copie des journaux de transaction SQL Server 2005, SQL Server 2008 ou SQL Server 2008 R2, revenez à l'instance du serveur principal d'origine. Pour plus d'informations, consultez Pour revenir à l'instance du serveur principal d'origine, plus loin dans cette section.

• Si vous avez supprimé la configuration de la copie des journaux de transaction avant le basculement, créez une nouvelle configuration de la 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 du serveur secondaire comme nouvelle instance du serveur principal, plus loin dans cette section.

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 au format SQL Server 2012 lorsque la première sauvegarde de 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 :

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

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 (SQL Server).

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 lors de 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.

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.

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.

   [!REMARQUE]

   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 temporaire (sur le serveur B), sauvegardez manuellement le journal des transactions avec l'option 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

Concepts

Sauvegardes du journal de transactions (SQL Server)

Appliquer les sauvegardes du journal de transactions (SQL Server)

Tables et procédures stockées liées à la copie des journaux de transaction