• Article

Mise à niveau de la copie des journaux de transaction SQL Server 2005 vers SQL Server 2008

Il est possible de conserver les configurations de la copie des journaux de transaction lors d'une mise à niveau de SQL Server 2005 vers SQL Server 2008. 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 la copie des journaux de transaction utilise l'option de configuration du niveau serveur de la compression de la sauvegarde par défaut 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 journaux peut être spécifié pour chaque configuration de la copie des journaux de transaction. Pour plus d'informations, consultez Procédure : activer la copie des journaux de transaction (SQL Server Management Studio).

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 :

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

Processus de mise à niveau pour les configurations 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 moniteur

Pour plus d'informations sur la mise à niveau de plusieurs serveurs secondaires, consultez la rubrique « Éléments à prendre en compte pour la mise à niveau de plusieurs serveurs secondaires », plus bas 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 SQL Server 2005 de la copie des journaux de transaction vers SQL Server 2008 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. 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 « Éléments à prendre en compte pour la mise à niveau de plusieurs instances de serveur secondaire », plus bas 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.

[!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 2008. 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 compliqué, vous pouvez augmenter la disponibilité de votre base de données en basculant le serveur principal SQL Server 2005 vers un serveur secondaire SQL Server 2008 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 original, puis, ultérieurement, créer une configuration à l'aide du nouveau serveur principal. Cette rubrique décrit chacun de ces 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 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 2008 et installer la copie des journaux de transaction sur une instance de serveur principal SQL Server 2008. 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 Suppression de la copie des journaux de transaction.

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 fichier journal après défaillance 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 fichier journal après défaillance 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 les travaux de sauvegarde qui ont été appliqués, utilisez la procédure stockée système sp_help_log_shipping_monitor (Transact-SQL) sur le serveur moniteur ou sur les serveurs primaires 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, consultez Procédure : démarrer un travail (SQL Server Management Studio) ou sp_start_job (Transact-SQL).

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

      L'exemple suivant restaure le fichier journal après défaillance 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 « Éléments à prendre en compte pour la mise à niveau de plusieurs instances de serveur secondaire », plus bas 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 2008

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

Procédure 3. Installer la copie des journaux de transaction sur SQL Server 2008

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 la copie des journaux de transaction SQL Server 2005, revenez à l'instance de serveur principal d'origine. 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 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 de serveur secondaire comme nouvelle instance de serveur principal », plus loin dans cette section.

Pour revenir à l'instance de 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 fichier journal après défaillance et placer la base de données hors connexion. La sauvegarde de fichier journal après défaillance 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 2008 lorsque la première sauvegarde de journal est restaurée.

  3. Restaurez la sauvegarde de fichier journal après défaillance, 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 de serveur secondaire comme nouvelle instance de 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 2008.

  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 configurer la copie des journaux de transaction

  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 Gestion des métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur.

Éléments à prendre en compte pour la mise à niveau de plusieurs instances de 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 moniteur

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

Mise à niveau avec basculement et 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.

  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 à l'aide de SQL Server Management Studio, consultez Procédure : activer la copie des journaux de transaction (SQL Server Management Studio).

Pour plus d'informations sur l'activation de la copie des journaux de transaction à l'aide de Transact-SQL, consultez Procédure : activer la copie des journaux de transaction (Transact-SQL).

Historique des modifications

Mise à jour du contenu

Mise à jour de la section « Mise à niveau de l'instance du serveur secondaire » pour indiquer que l'option RESTORE WITH STANDBY n'est pas prise en charge pour une base de données qui requiert une mise à niveau.