Mise à niveau des bases de données répliquées

  • Article

Mis à jour : 17 juillet 2006

SQL Server 2005 prend en charge la mise à niveau des bases de données répliquées à partir des versions précédentes de SQL Server ; il n'est pas nécessaire d'interrompre l'activité des autres nœuds lorsqu'un nœud est en cours de mise à niveau. Prenez soin de respecter les règles relatives aux versions qui sont prises en charge dans une topologie :

  • SQL Server version 7.0 Service Pack 4 (SP4) est la version minimale requise pour participer à une topologie de réplication avec SQL Server 2005. Si vous utilisez SQL Server 2000, le Service Pack 3 (SP3) ou ultérieur est requis.
  • Toute version convient pour le serveur de distribution dès lors qu'elle est égale ou supérieure à celle du serveur de publication (en général, l'instance du serveur de distribution est la même que celle du serveur de publication).
  • Toute version convient pour le serveur de publication dès lors qu'elle est inférieure ou égale à celle du serveur de distribution.
  • La version de l'Abonné dépend du type de publication :
    • La version d'un Abonné en lecture seule vers une publication transactionnelle peut être n'importe laquelle des deux versions du serveur de publication. Par exemple : Un serveur de publication SQL Server version 7.0 en cours d'exécution peut avoir des Abonnés SQL Server 2005 et un serveur de publication SQL Server 2005 peut avoir des Abonnés SQL Server version 7.0.
    • La version d'un Abonné pouvant être mis à jour vers une publication transactionnelle SQL Server 2005 peut être toute version égale ou supérieure à SQL Server 2000 SP3.
    • La version d'un Abonné à une publication de fusion peut être toute version inférieure ou égale à celle du serveur de publication.
ms143699.note(fr-fr,SQL.90).gifRemarque :
Cette rubrique est disponible dans la documentation d'aide du programme d'installation et dans la documentation en ligne de SQL Server 2005. Les liens vers des rubriques qui s'affichent en gras dans la documentation d'aide du programme d'installation font référence à des rubriques qui sont exclusivement disponibles dans la documentation en ligne.

Mise à niveau vers Standard Edition, Workgroup Edition ou Express Edition

Avant toute mise à niveau d'une édition de SQL Server 2005 vers une autre, vérifiez que la fonctionnalité en cours d'utilisation est prise en charge dans l'édition vers laquelle vous effectuez la mise à niveau. Pour plus d'informations, consultez la section « Fonctionnalités de réplication SQL Server 2005 » dans la rubrique Fonctionnalités prises en charge par les éditions de SQL Server 2005.

Nouveau modèle de sécurité de l'Agent de réplication

Dans les versions précédentes de SQL Server, les agents s'exécutaient par défaut sous le compte du service SQL Server Agent. SQL Server 2005 permet de contrôler soigneusement chaque compte sous lequel les agents de réplication s'exécutent et établissent des connexions intégrées Windows aux bases de données et à d'autres ressources ; un compte différent peut être spécifié pour chaque agent. Pour plus d'informations, consultez Considérations de sécurité pour la réplication et Modèle de sécurité de l'Agent de réplication.

Le nouveau modèle de sécurité a les implications suivantes dans la mise à niveau et l'exécution de plusieurs versions de SQL Server dans une topologie :

  • Les scripts de réplication créés à partir de SQL Server 2000 ou de SQL Server 7.0 doivent être mis à niveau vers SQL Server 2005 afin que vous bénéficiiez des améliorations en matière de sécurité. Pour plus d'informations, consultez How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
  • Un serveur de distribution ou un Abonné mis à niveau à partir d'une version précédente de SQL Server vers SQL Server 2005 continue d'être exécuté sous le compte de l'Agent SQL Server et a vraisemblablement plus de privilèges qu'il n'en nécessite. Après la mise à jour, nous vous recommandons de spécifier des comptes distincts pour les agents, avec les privilèges minimum appropriés. Pour spécifier des comptes distincts :
    1. Générez le script de la publication et des abonnements.
    2. Modifiez ces scripts. Pour plus d'informations, consultez How to: Upgrade Replication Scripts (Replication Transact-SQL Programming).
    3. Supprimez la publication et les abonnements. Pour plus d'informations, consultez Publication de données et d'objets de base de données et Abonnement à des publications.
    4. Recréez-les à l'aide des scripts modifiés.
      Pour plus d'informations sur les privilèges requis par les agents, consultez Modèle de sécurité de l'Agent de réplication ; pour plus d'informations sur la gestion des connexions et des mots de passe, consultez Gestion des connexions et des mots de passe dans la réplication. Les nouvelles configurations de réplication créées après une mise à niveau requièrent une configuration de compte spécifique pour chaque agent de réplication.
    ms143699.note(fr-fr,SQL.90).gifRemarque :
    Tous les agents configurés pour utiliser l'authentification SQL Server pour les connexions de bases de données locales sont modifiés pour utiliser l'authentification Windows. Les connexions locales sont les connexions effectuées par un agent à une instance SQL Server qui s'exécute sur le même ordinateur que l'agent. Par exemple, l'Agent de fusion pour un abonnement par extraction de données s'exécute chez l'Abonné, si bien que les connexions qu'il établit avec l'Abonné sont des connexions locales.
  • Les participants d'une topologie de réplication exécutant des versions précédentes de SQL Server gardent l'ancien modèle de sécurité de réplication tel quel. Par exemple :
    • Un abonnement par extraction de données vers un Abonné exécutant SQL Server 2000 ou SQL Server version 7.0 n'utilise pas le nouveau modèle de sécurité, car l'Agent de fusion ou de distribution est créé chez l'Abonné.
    • Un abonnement par envoi de données à partir d'un serveur de distribution exécutant SQL Server 2005 vers un Abonné exécutant SQL Server 2000 ou SQL Server version 7.0 utilise le nouveau modèle de sécurité, car l'Agent de fusion ou de distribution est créé sur le serveur de distribution.
    • Un serveur de publication exécutant SQL Server 2000 ou SQL Server version 7.0 avec un serveur de distribution exécutant SQL Server 2005 n'utilise pas le nouveau modèle de sécurité (pour l'Agent de capture instantanée, l'Agent de lecture de journal ou l'Agent de lecture de la file d'attente), car les agents sont créés dans le contexte de la base de données de publication.

Exécution des agents après la mise à niveau pour la réplication de fusion

Après la mise à niveau, exécutez l'Agent de capture instantanée pour chaque publication de fusion et l'Agent de fusion pour chaque abonnement afin de mettre à jour les métadonnées de réplication. Vous n'avez pas à appliquer la nouvelle capture instantanée, car elle n'est pas nécessaire pour réinitialiser les abonnements. Les métadonnées d'abonnement sont mises à jour lors de la première exécution de l'Agent de fusion après la mise à niveau. Ceci signifie que la base de données d'abonnement peut rester en ligne et active durant la mise à niveau du serveur de publication.

La réplication de fusion stocke les métadonnées de publication et d'abonnement dans un certain nombre de tables système des bases de données de publication et d'abonnement. L'exécution de l'Agent de capture instantanée met à jour les métadonnées d'abonnement et l'exécution de l'Agent de fusion met à jour les métadonnées d'abonnement. Il faut uniquement générer une capture instantanée de publication. Si une publication de fusion utilise des filtres paramétrés, chaque partition a également une capture instantanée. Il n'est pas nécessaire de mettre à jour ces captures instantanées partitionnées. (Dans SQL Server 2000, les filtres paramétrés étaient désignés comme des filtres dynamiques et les captures instantanées partitionnées étaient désignées comme des captures instantanées dynamiques.)

Exécutez les agents à partir de Microsoft SQL Server Management Studio, du Moniteur de réplication ou de la ligne de commande. Pour plus d'informations sur l'exécution de l'Agent de capture instantanée, consultez les rubriques suivantes :

Pour plus d'informations sur l'exécution de l'Agent de fusion, consultez les rubriques suivantes :

Après avoir mis à niveau SQL Server dans une topologie qui utilise la réplication de fusion, modifiez le niveau de compatibilité de toutes les publications si vous voulez utiliser les nouvelles fonctionnalités. Pour plus d'informations, consultez Utilisation de plusieurs versions de SQL Server dans une topologie de réplication.

Synchronisation Web pour la réplication de fusion

L'option de synchronisation Web pour la réplication de fusion requiert la copie de l'Écouteur de réplication SQL Server (replisapi.dll) dans le répertoire virtuel sur le serveur IIS (Internet Information Services) utilisé pour la synchronisation. Lorsque vous configurez la synchronisation Web, le fichier est copié dans le répertoire virtuel par l'Assistant Configuration de la synchronisation Web. Si vous mettez à niveau les composants SQL Server installés sur le serveur IIS, vous devez manuellement copier replisapi.dll depuis le répertoire COM vers le répertoire virtuel sur le serveur IIS. Pour plus d'informations sur la configuration de la synchronisation Web, consultez Configuration de la synchronisation Web.

Restauration d'une base de données répliquée à partir d'une version précédente

Pour vous assurer que les paramètres de réplication sont conservés lorsque vous restaurez la sauvegarde d'une base de données répliquée à partir d'une version précédente : effectuez la restauration vers un serveur et une base de données du même nom que le serveur et la base de données à l'origine de la sauvegarde.

Voir aussi

Concepts

Compatibilité descendante de la réplication
Utilisation de plusieurs versions de SQL Server dans une topologie de réplication

Autres ressources

Administration de la réplication
Amélioration de la réplication
Mises à niveau de la version et de l'édition

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

17 juillet 2006
Contenu modifié
  • Ajout d'une remarque indiquant que les bases de données d'abonnement peuvent rester en ligne et actives durant la mise à niveau d'un serveur de publication.