Partager via

  • Article

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

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

  • Versions de SQL Server prises en charge

  • Mappage des types de données de SQL Server 2008 pour les versions antérieures

  • Restauration d'une base de données répliquée à partir d'une version antérieure

  • Niveau de compatibilité pour les publications de fusion

Pour plus d'informations sur la façon de répliquer des données vers SQL Server Express et SQL Server Compact 3.5 SP1, consultez Réplication de données vers SQL Server Express et Réplication de données vers SQL Server Compact. 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 2008.

Versions de SQL Server prises en charge

SQL Server 2000 et SQL Server 2005 peuvent tous deux participer aux topologies de réplication avec SQL Server 2008. Pour SQL Server 2000 la version minimale est Service Pack 3 (SP3). Pour SQL Server 2005 la version minimale est Service Pack 2 (SP2).

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

[!REMARQUE]

Le format de stockage sur disque de SQL Server étant le même dans les environnements 64 bits et 32 bits, une topologie de réplication peut combiner des instances de serveur qui s'exécutent dans un environnement 32 bits et des 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.)

Pour la réplication transactionnelle, la version d'un Abonné à une publication transactionnelle peut être n'importe laquelle des deux versions du serveur de publication. Par exemple, un serveur de publication SQL Server 2000 peut avoir des Abonnés SQL Server 2008 et un serveur de publication SQL Server 2008 peut avoir des Abonnés SQL Server 2000.

Pour la réplication de fusion, 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 antérieures, consultez « Niveau de compatibilité pour les publications de fusion » plus loin dans cette rubrique. 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 2008.

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

SQL Server 2005 et SQL Server 2008 peuvent être utilisés 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 des propriétés introduites dans SQL Server 2005:

Si vous avez un serveur de publication et serveur de distribution qui exécutent SQL Server 2000, vous pouvez modifier les informations d'identification sous lesquelles 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 2008, 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 les travaux d'agent créés après que la procédure a été appelée. Pour modifier les informations d'identification des travaux d'agent existants, appelez l'une des quatre procédures répertoriées précédemment.

Mappage de nouveaux types de données pour les versions antérieures

SQL Server 2008 et SQL Server 2005 prennent en charge plusieurs nouveaux types de données. Comme illustré dans le tableau suivant, ces nouveaux types de données sont mappés vers des types de données compatibles chez l'Abonné si des abonnements par émission de données à partir d'un serveur de distribution de SQL Server 2005 ou SQL Server 2008 sont utilisés. Si les nouveaux types de données sont répliqués sur des Abonnés qui exécutent des versions antérieures de SQL Server, vous devez vérifier que les types de données sont mappés convenablement :

Type de données de SQL Server 2008

Type de données SQL Server 2005

Type de données SQL Server 2000

Fonction CLR définie par l'utilisateur (UDT) : 8 000 octets ou moins

UDT

image

UDT : plus de 8 000 octets1

varbinary(max)

image

date2, 3

nvarchar(10)

nvarchar(10)

datetime22, 3

nvarchar(27)

nvarchar(27)

datetimeoffset2, 3

nvarchar(34)

nvarchar(34)

Attribut FILESTREAM1, 4

varbinary(max)

Non pris en charge

geography et geometry1, 3

varbinary(max)

image

hierarchyid1, 5

varbinary(max)

image

nvarchar(max)

nvarchar(max)

ntext

time2, 3

nvarchar(16)

nvarchar(16)

varchar(max)

varchar(max)

text

varbinary(max)

varbinary(max)

image

xml

xml

ntext

1 Les mappages pour les types UDT, FILESTREAM, geography, geometry et hierarchyid ne sont pas pris en charge pour les publications transactionnelles avec les abonnements pouvant être mis à jour. Incluez uniquement ces types si tous les Abonnés de mise à jour exécutent SQL Server 2008 ou une version ultérieure.

2 La réplication ne vérifie pas le format des données insérées au niveau de l'Abonné. Par conséquent, votre application doit s'assurer que les données insérées sont du format correct pour les colonnes de type date, datetime2, datetimeoffset et time. Pour cela, on utilise en général une contrainte. Si les données ne sont pas du format correct, l'insertion au niveau du serveur de publication échoue.

3 Les Abonnés SQL Server Compact 3.5 convertissent ces types après qu'ils ont été répliqués sur l'Abonné. Pour plus d'informations sur les mappages des types de données pour SQL Server Compact 3.5, consultez la documentation SQL Server Compact 3.5.

Si vous mappez des colonnes de type geography ou geometry à varbinary(max) ou image, vous ne pouvez pas répliquer de contraintes par défaut pour ces colonnes. Les conséquences sont les suivantes :

4 FILESTREAM est un attribut sur une colonne varbinary(max). Pour plus d'informations sur l'utilisation de colonnes FILESTREAM dans les tables répliquées, consultez la section « Replication » de Utilisation de FILESTREAM avec d'autres fonctionnalités SQL Server. Les colonnes ayant l'attribut FILESTREAM ne doivent pas être incluses dans les publications qui utilisent une capture instantanée de mode caractère.

5 La prise en charge des colonnes de type hierarchyid dépend du type de réplication et des versions de SQL Server utilisées. Pour plus d'informations, consultez la section « Utilisation de colonnes hierarchyid dans les tables répliquées » de la rubrique hierarchyid (Transact-SQL). Pour la réplication de fusion, hierarchyid est mappé avec image lorsque le niveau de compatibilité de la publication est 100RTM et qu'une capture instantanée de mode caractère est utilisée.

Réplication de types de données XML

Lors de la réplication de types de données XML vers SQL Server Compact 3.5 SP1, la réplication de fusion les mappe avec Ntext. Les données XML sur SQL Server 2008 ont des octets de préfixe pour le codage UTF-16. Ces octets sont conservés lors de la réplication de SQL Server vers SQL Server Compact 3.5 SP1 en utilisant la réplication de fusion. Ces octets de préfixe ne sont pas compris par SQL Server Management Studio lors de l'affichage de la colonne Ntext de la base de données SQL Server Compact 3.5 SP1. Par conséquent, ces octets sont affichés sous la forme de caractères incompréhensibles.

La collection de schémas XML dans SQL Server 2008 a été mise à jour. Cela a un effet lors de la réplication de colonnes XML liées à des schémas XML de SQL Server 2008 vers SQL Server 2005.

Les fuseaux horaires ne sont pas obligatoires pour les valeurs de schéma XML date, time et datetime dans SQL Server 2008. Cela signifie que si aucun fuseau horaire n'est spécifié sur la colonne XML du serveur de publication SQL Server 2008, la modification ne sera pas appliquée aux abonnés SQL Server 2005 car SQL Server 2005 exige qu'un fuseau horaire soit spécifié.

Les informations de fuseau horaire relatives aux valeurs typées de schéma XML date, time et datetime de serveur de publication SQL Server 2008 seront converties au fuseau horaire UTC-0 dans SQL Server 2005. Cela est représenté par l'indicateur de fuseau horaire Z.

Les types date, time et datetime du schéma XML SQL Server 2008 prennent en charge une précision plus élevée. Par conséquent, ces valeurs sont arrondies lors de la réplication vers SQL Server 2005.

Lors de la réplication de valeurs date ou datetime de schéma XML de SQL Server 2005 vers SQL Server 2008, les valeurs avec une année négative ne sont pas appliquées sur SQL Server 2008 car elles ne sont pas prises en charge sur SQL Server 2008.

Dans ces situations, les méthodes sp_table_validation et Validate sur les agents de réplication peuvent échouer. Pour plus d'informations, consultez la section « Mise à niveau de XML typé de SQL Server 2005 vers SQL Server 2008 » dans Comparaison du XML typé et du XML non typé.

Publication de données compressées

SQL Server 2008 prend en charge la compression de page et de ligne pour les tables et les index. Pour plus d'informations sur la prise en charge de la réplication pour les données compressées, consultez « Impact de la compression sur la réplication » dans Création de tables et d'index compressés.

Restauration d'une base de données répliquée à partir d'une version antérieure

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 antérieure. 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 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 80RTM (SQL Server 2000 sans Service Pack installé) à 100RTM pour SQL Server 2008. Le niveau de compatibilité est spécifié par l'une des méthodes suivantes :

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é ; toutefois, ils nécessitent l'Agent de fusion fourni avec SQL Server 2005 et versions ultérieures. Les Abonnés qui exécutent des versions antérieures de SQL Server fonctionnent comme si la fonctionnalité n'était pas activée.

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

Voici quelques comportements importants du niveau de compatibilité de publication à considérer :

  • 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 de SQL Server antérieures à SQL Server 2005, le niveau de compatibilité de la publication était automatiquement augmenté lorsque vous activiez une fonctionnalité à un niveau supérieur. À compter de SQL Server 2005, vous devez manuellement affecter la valeur 90RTM ou plus au niveau de compatibilité de la publication avant d'activer la fonctionnalité qui requiert ce niveau de compatibilité.

  • 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 ou plus, 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 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 ou plus, vous devez supprimer toutes les publications existantes à l'exception d'une seule, augmenter le niveau de la publication restante vers 90RTM ou plus, recréer les publications supprimées au niveau 90RTM ou plus et créer la nouvelle publication avec un niveau de 90RTM ou plus.

Composants requis et niveaux de compatibilité pour la synchronisation Web

SQL Server 2008 prend en charge la synchronisation Web pour les Abonnés qui exécutent SQL Server 2005, SQL Server 2008 et SQL Server Compact 3.5 versions 3.0, 3.1 et 3.5. Le tableau suivant répertorie le niveau de compatibilité de publication et les composants serveur requis pour chaque type d'Abonné.

Version du serveur de publication

Version d'Abonné

Niveau de compatibilité de publication requis

Composants requis sur le serveur IIS

SQL Server 2008

SQL Server 2008

100RTM

Composants IIS de SQL Server 2008

SQL Server 2008

SQL Server Compact 3.5 3.0, 3.1 et 3.5

90RTM

Composants IIS SQL Server Compact 3.5 SP1 et composants IIS SQL Server 2008

SQL Server 2008

SQL Server 2005

90RTM

Composants IIS de SQL Server 2008

SQL Server 2005

SQL Server 2005

90RTM

Composants IIS de SQL Server 2005

SQL Server 2005

SQL Server Compact 3.5 3.0, 3.1 et 3.5

90RTM

Composants IIS SQL Server Compact 3.5 SP1 et composants IIS SQL Server 2005

SQL Server 2005

SQL Server 2008

Non applicable1

Non applicable1

1  Cette configuration n'est pas prise en charge car la version de serveur de publication doit être supérieure ou égale à la version d'Abonné.