Partager via


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

Mis à jour : 15 septembre 2007

La réplication prend en charge la réplication de données vers différentes versions de Microsoft SQL Server. Cette rubrique traite des sujets suivants :

  • Versions de SQL Server prises en charge
  • Mappage des types de données de SQL Server 2005 pour les versions précédentes
  • Restauration d'une base de données répliquée à partir d'une version précédente
  • Niveau de compatibilité pour les publications de fusion

Pour plus d'informations sur la réplication de données vers Microsoft SQL Server 2005 Express Edition et Microsoft SQL Server Compact Edition, consultez Réplication de données vers SQL Server Express et Réplication de données vers SQL Server Compact Edition. Pour plus d'informations sur les fonctionnalités prises en charge par chaque édition de SQL Server, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2005.

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

Versions de SQL Server Versions prises en charge

SQL Server version 7.0 Service Pack 4 (SP4) est la version la plus ancienne qui peut participer à une topologie de réplication avec SQL Server 2005. Si vous utilisez SQL Server 2000, SP3 ou version ultérieure est requis.

Lorsque vous effectuez une réplication entre ou parmi des versions différentes de SQL Server, les fonctionnalités disponibles se limitent souvent à celles de la plus ancienne version utilisée. Par exemple, si vous mettez à niveau un serveur de distribution vers une instance de SQL Server 2005, mais que vous avez un serveur de publication qui exécute une instance de SQL Server 2000 et un Abonné exécutant une instance de SQL Server 7.0, vous êtes limité aux fonctionnalités générales et aux fonctionnalités de réplication de SQL Server 7.0.

ms143241.note(fr-fr,SQL.90).gifRemarque :
Dans la mesure où le format de stockage sur disque de SQL Server est le même dans les environnements 64 bits et 32 bits, une topologie de réplication peut combiner les instances de serveur qui s'exécutent dans un environnement 32 bits et les instances de serveur qui s'exécutent dans un environnement 64 bits.

Pour tous les types de réplication, la version du serveur de distribution ne doit pas être antérieure à la version du serveur de publication (dans la plupart des cas les deux versions sont identiques). Vous pouvez utiliser SQL Server 2005 comme serveur de distribution pour SQL Server 2005 et SQL Server 2000, mais pas pour SQL Server 7.0. Les tableaux suivants fournissent des informations supplémentaires sur les versions de SQL Server pouvant participer dans la même topologie. Pour plus d'informations sur les fonctionnalités de réplication prises en charge dans les différentes éditions de SQL Server, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2005.

Réplication transactionnelle et réplication de capture instantanée avec des Abonnés en lecture seule

Distributeur

SQL Server 7.0

SQL Server 2000

SQL Server 2005

Éditeur

SQL Server 7.0

SQL Server 7.0

SQL Server 2000

SQL Server 2000

SQL Server 2005

Abonnés

SQL Server 7.0

SQL Server 2000

SQL Server 2005

SQL Server 7.0

SQL Server 2000

SQL Server 2005

SQL Server 7.0

SQL Server 2000

SQL Server 2005

Le tableau précédent indique qu'un Abonné en lecture seule à une publication transactionnelle peut être n'importe laquelle des deux versions du serveur de publication. Par exemple, un serveur de publication SQL Server 7.0 peut avoir des Abonnés SQL Server 2005 et un serveur de publication SQL Server 2005 peut avoir des Abonnés SQL Server 7.0.

Réplication transactionnelle avec des abonnés mis à jour

Distributeur

SQL Server 7.0

SQL Server 2000

SQL Server 2005

Éditeur

SQL Server 7.01

SQL Server 7.01

SQL Server 20002

SQL Server 20002

SQL Server 20053

Abonnés

SQL Server 7.0

SQL Server 7.0

SQL Server 2000

SQL Server 2005

SQL Server 7.0

SQL Server 2000

SQL Server 2005

1 Pour un serveur de publication SQL Server 7.0, seuls les abonnés SQL Server 7.0 sont pris en charge.

2 Pour un serveur de publication SQL Server 2000, les abonnés SQL Server 7.0, SQL Server 2000, et SQL Server 2005 sont pris en charge.

3 Pour un serveur de publication SQL Server 2005, les abonnés SQL Server 2000 et SQL Server 2005 sont pris en charge.

Réplication de fusion

Distributeur

SQL Server 7.0

SQL Server 2000

SQL Server 2005

Éditeur

SQL Server 7.0

SQL Server 7.0

SQL Server 2000

SQL Server 2000

SQL Server 2005

Abonnés

SQL Server 7.0

SQL Server 7.0

SQL Server 2000

SQL Server 7.0

SQL Server 2000

SQL Server 2005

Le tableau ci-dessus indique qu'un Abonné à une publication de fusion peut être n'importe quelle version antérieure à la version du serveur de publication. Pour plus d'informations sur la compatibilité des versions précédentes, consultez « Niveau de compatibilité pour les publications de fusion » plus loin dans cette rubrique.

SQL Server 7.0 et SQL Server Management Studio

SQL Server Management Studio peut se connecter à des instances exécutant SQL Server 2000 ou une version ultérieure. Pour les Abonnés exécutant SQL Server 7.0 :

  • Les abonnements et les publications peuvent être créés avec les outils de SQL Server 7.0, les outils de SQL Server 2000, SQL Distributed Management Objects (SQL-DMO) ou des procédures stockées.
  • Les agents des abonnements par extraction de données ne peuvent pas être démarrés à partir de Management Studio ni du Moniteur de réplication. Les agents peuvent être paramétrés pour s'exécuter suivant une planification créée lors de la création de l'abonnement ou peuvent être exécutés à la demande à partir de l'invite de commandes.

Les abonnements des Abonnés exécutant SQL Server 7.0 apparaissent dans Management Studio et dans le Moniteur de réplication après leur création. Pour plus d'informations sur la création d'abonnements et de publications et sur l'exécution des agents, consultez la documentation en ligne de SQL Server 7.0.

Utilisation d'un serveur de distribution SQL Server 2005 avec un serveur de publication SQL Server 2000

SQL Server 2005 peut être utilisé comme serveur de distribution distant pour les serveurs de publication exécutant SQL Server 2000. Pour modifier les propriétés de l'agent dans ce cas de figure, exécutez les procédures stockées suivantes sur le serveur de distribution. Ces procédures vous permettent de modifier les propriétés qui sont nouvelles dans SQL Server 2005 :

Si vous disposez d'un serveur de publication et d'un serveur de distribution exécutant SQL Server 2000, il est possible de modifier les informations d'identification sur la base desquelles les agents établissent des connexions à l'aide de sp_changedistpublisher et sp_changesubscriber. Toutefois, si vous mettez à niveau le serveur de distribution vers SQL Server 2005, ces procédures ne peuvent pas être utilisées pour modifier les informations d'identification utilisées dans les travaux d'agent existants (les procédures affectent en revanche les travaux d'agent qui sont créés après l'appel de la procédure). Pour modifier les informations d'identification des travaux d'agent existants, appelez l'une des quatre procédures répertoriées ci-dessus.

Mappage des types de données de SQL Server 2005 pour les versions précédentes

SQL Server 2005 a introduit un certain nombre de nouveaux types de données. Ces nouveaux types de données sont mappés vers des types de données compatibles chez l'Abonné si des abonnements par envoi de données à partir d'un serveur de distribution de SQL Server 2005 sont utilisés.

Type de données SQL Server 2005 Type de données SQL Server 2000 ou SQL Server 7.0

xml

ntext

Types CLR définis par l'utilisateur (UDT)

image

varchar(max)

text

nvarchar(max)

ntext

varbinary(max)

image

Vous devez vérifier que les types varchar(max), nvarchar(max), varbinary(max), xmlL et les types CLR définis par l'utilisateur sont mappés de manière appropriée s'ils sont répliqués vers des Abonnés exécutant des versions antérieures de SQL Server (ceci se fait par défaut pour les articles des publications de fusion). Le comportement de mappage de ces types est contrôlé par les options de schéma 0x20, 0x10000000 et 0x20000000 pour sp_addarticle et sp_addmergearticle. Pour plus d'informations sur la définition des options de schéma, consultez Procédure : spécifier des options de schéma (SQL Server Management Studio) et How to: Specify Schema Options (Replication Transact-SQL Programming).

SQL Server 2000 a introduit deux types de données qui sont mappés à des types de données compatibles pour SQL Server 7.0. Ces nouveaux types de données sont mappés vers des types de données compatibles chez l'Abonné si des abonnements par envoi de données à partir d'un serveur de distribution de SQL Server 2005 ou SQL Server 2000sont utilisés.

Type de données SQL Server 2000 ou SQL Server 2005 Type de données SQL Server 7.0

SQL_VARIANT

IMAGE

BIGINT

DECIMAL

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

Vous pouvez conserver les paramètres de réplication lors de la restauration d'une sauvegarde d'une base de données répliquée à partir d'une version précédente. Si vous effectuez les restaurations 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 ou si vous spécifiez l'option KEEP_REPLICATION, les paramètres de la réplication sont préservés. Pour plus d'informations, consultez RESTORE (Transact-SQL). Après avoir restauré la base de données, exécutez sp_vupgrade_replication (Transact-SQL) pour mettre à niveau les données système et de schéma pour prendre en charge la réplication dans la version actuelle du produit.

Même s'il est possible de préserver la réplication après une restauration à partir d'une sauvegarde d'une version antérieure, celle-ci est rarement utilisée comme option de mise à niveau. Il est plus courant de mettre à niveau la base de données répliquée dans le cadre d'une mise à niveau du produit ou de recréer la base de données et la configuration de réplication à partir d'un jeu de scripts.

Niveau de compatibilité pour les publications de fusion

La réplication de fusion utilise le niveau de compatibilité de la publication pour déterminer les fonctionnalités qui peuvent être utilisées par les publications dans une base de données donnée. Les valeurs se situent dans la plage de 70RTM (SQL Server 7.0 sans Service Pack installé) à 90RTM. Le niveau de compatibilité est spécifié :

Les fonctionnalités suivantes nécessitent un niveau de compatibilité de 90RTM ou supérieur :

Les fonctionnalités suivantes ne dépendent pas du niveau de compatibilité, mais elles requièrent l'Agent de fusion qui accompagne SQL Server 2005 ; les Abonnés qui exécutent des versions antérieures de SQL Server fonctionnent comme si cette fonctionnalité n'était pas activée :

Comportement du niveau de compatibilité de la publication dans SQL Server 2005

Il est important de comprendre le comportement du niveau de compatibilité de la publication :

  • Le niveau de compatibilité de la publication n'est pas lié au niveau de compatibilité de la base de données.
  • Si vous créez une publication à l'aide de sp_addmergepublication ou via Replication Management Objects (RMO), le niveau de compatibilité de la publication est défini par défaut à 80RTM. Si vous créez une publication dans l'Assistant Nouvelle publication, le niveau de compatibilité de la publication est déterminé selon les options sélectionnées dans la page Types d'Abonnés de l'Assistant.
  • Dans les versions précédentes de SQL Server, le niveau de compatibilité de la publication était automatiquement augmenté lorsque vous activiez une fonctionnalité à un niveau supérieur. Dans SQL Server 2005, vous devez manuellement affecter la valeur 90RTM au niveau de compatibilité de la publication avant d'activer la fonctionnalité qui requiert ce niveau de compatibilité.
    Si vous mettez à niveau un serveur de publication à partir de SQL Server 7.0 et que vous sélectionnez une ou plusieurs fonctionnalités qui nécessitent un niveau de compatibilité de 80RTM, ce dernier est automatiquement augmenté.
  • Le niveau de compatibilité de la publication peut uniquement être abaissé si l'Agent de capture instantanée n'a pas démarré et qu'il n'y a pas d'abonnement à la publication.
  • Toutes les publications de la même base de données doivent avoir le même niveau de compatibilité. Cette exigence entraîne les conséquences suivantes :
    • Si une base de données contient une publication qui a le niveau de compatibilité le plus bas (en l'occurrence, 80RTM) et que vous voulez ajouter une publication dans la base ayant le niveau 90RTM, vous devez augmenter manuellement le niveau de compatibilité de la première publication avant d'ajouter la nouvelle.
    • Si une base de données contient une ou plusieurs publications avec des niveaux de compatibilité inférieurs, et que vous souhaitez ajouter une autre publication dans la même base de données avec un niveau de 90RTM, vous devez supprimer toutes les publications existantes à l'exception d'une seule, augmenter le niveau de la publication restante vers 90RTM, recréer les publications supprimées au niveau 90RTM et créer la nouvelle publication avec un niveau de 90RTM.

Voir aussi

Concepts

Compatibilité descendante de la réplication
Mise à niveau des bases de données répliquées

Autres ressources

Amélioration de la réplication

Aide et Informations

Assistance sur SQL Server 2005

Historique des modifications

Version Historique

15 septembre 2007

Nouveau contenu :
  • Ajout d'une remarque sur le format de stockage sur disque de SQL Server identique dans les environnements 64 bits et 32 bits.

14 avril 2006

Contenu modifié :
  • Ajout des tableaux pour clarifier quelles versions de SQL Server peuvent être utilisées dans la même topologie de réplication.
  • Des informations ont été ajoutées au sujet des options de schéma utilisées pour mapper les types de données.
  • Suppression des informations indiquant que SQL Server 7.0 peut utiliser une instance de SQL Server 2005 comme serveur de distribution distant. Cette configuration n'est pas prise en charge.