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 :
Le mappage est effectué par défaut pour les articles dans les publications de fusion, mais pas pour les articles dans les publications transactionnelles ou de capture instantanée. Pour les publications de fusion, la façon dont les types sont mappés est déterminée par le niveau de compatibilité de la publication. Par exemple, si une colonne est de type geography et que le niveau de compatibilité est 90RTM, le type est mappé avec varbinary(max). Si le niveau de compatibilité est 80RTM, le type est mappé avec image.
Le comportement de mappage est contrôlé par le paramètre @schema\_option de sp_addarticle et sp_addmergearticle.
Pour plus d'informations sur la façon de définir des options de schéma, consultez Procédure : spécifier des options de schéma (SQL Server Management Studio) et Procédure : spécifier des options de schéma (programmation Transact-SQL de la réplication).
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 :
Si vous avez déjà une contrainte par défaut sur le serveur de publication, supprimez la contrainte ou indiquez qu'elle ne doit pas être répliquée. Pour spécifier qu'elle ne doit pas être répliquée, utilisez l'option de schéma d'article pour les contraintes par défaut :
Sélectionnez une valeur False pour l'option Copier les spécifications de valeurs par défaut. Pour plus d'informations, consultez Procédure : spécifier des options de schéma (SQL Server Management Studio).
Désactivez l'option de schéma 0x800. Pour plus d'informations, consultez Procédure : spécifier des options de schéma (programmation Transact-SQL de la réplication).
Si vous souhaitez ajouter une contrainte par défaut sur le serveur de publication, spécifiez d'abord que les modifications de schéma ne doivent pas être répliquées. Pour plus d'informations, consultez Procédure : répliquer des modifications de schéma (SQL Server Management Studio) et Procédure : répliquer des modifications de schéma (programmation Transact-SQL de la réplication).
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 :
En utilisant le paramètre @publication\_compatibility\_level de sp_addmergepublication. Pour plus d'informations, consultez Procédure : définir le niveau de compatibilité des publications de fusion (programmation Transact-SQL de la réplication).
Dans la page Types d'abonnés de l'Assistant Nouvelle publication. Pour plus d'informations sur l'exécution de cet Assistant, consultez Procédure : créer une publication et définir des articles (SQL Server Management Studio).
Dans la page Général de la boîte de dialogue Propriétés de la publication - <Publication>. Pour plus d'informations, consultez Procédure : définir le niveau de compatibilité pour les publications de fusion (SQL Server Management Studio).
Les fonctionnalités suivantes nécessitent un niveau de compatibilité de 90RTM ou supérieur :
Enregistrements logiques. Pour plus d'informations, consultez Regroupements des modifications apportées à des lignes connexes à l'aide d'enregistrements logiques.
Options de téléchargement de l'Abonné. Pour plus d'informations, consultez Optimisation des performances de la réplication de fusion avec les articles en téléchargement seul.
Partitions qui ne se chevauchent pas. Pour plus d'informations, consultez Filtres de lignes paramétrés.
Gestionnaires de logique métier. Pour plus d'informations, consultez Exécution de la logique métier lors de la synchronisation de fusion.
Modifications de schéma qui utilisent des instructions ALTER <OBJECT>. Pour plus d'informations, consultez Modification du schéma dans les bases de données de publication.
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.
Partitions précalculées. Pour plus d'informations, consultez Optimisation des performances des filtres paramétrés avec des partitions précalculées.
Synchronisation Web. Pour plus d'informations, consultez Synchronisation Web pour la réplication de fusion.
Agents de phases parallèles (en spécifiant -ParallelUploadDownload pour l'Agent de fusion). Pour plus d'informations, consultez Agent de fusion de réplication.
Les fonctionnalités de capture instantanée pour les publications qui utilisent des filtres paramétrés. Ces fonctionnalités fournissent les capacités suivantes :
pour un Abonné de demander une capture instantanée s'il n'y en a pas de disponible pour sa partition ;
pour un administrateur de prégénérer et de planifier la génération de captures instantanéee ;
de livrer des captures instantanées paramétrées en utilisant FTP.
Pour plus d'informations, consultez Captures instantanées des publications de fusion avec des filtres paramétrés et Transfert de captures instantanées via FTP.
Enregistrement de l'historique amélioré et statistiques de niveau article dans le Moniteur de réplication Pour plus d'informations, consultez Procédure : afficher des informations et effectuer des tâches relatives à un abonnement (moniteur de réplication).
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é.