Remarque
L’accès à cette page requiert une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page requiert une autorisation. Vous pouvez essayer de modifier des répertoires.
S'applique à :SQL Server
Les abonnés non-SQL Server suivants peuvent s’abonner à des publications snapshot et transactionnelles en utilisant des abonnements push. Les deux versions les plus récentes de chaque base de données indiquaient des abonnements de support en utilisant la version la plus récente du fournisseur OLE DB mentionné.
La réplication hétérogène vers les abonnés non-SQL Server est obsolète. Oracle publishing est obsolète. Pour déplacer des données, créez des solutions en utilisant la capture de données de changement et le SSIS.
Attention
Cette fonctionnalité sera supprimée dans une version future de SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité.
| Base de données | Système d’exploitation | Fournisseur |
|---|---|---|
| Oracle | Toutes les plateformes prises en charge par Oracle | Fournisseur OLE DB Oracle (fourni par Oracle) |
| IBM Db2 | MVS, AS400, Unix, Linux, Windows sauf 9.x | Fournisseur OLE DB pour Microsoft Host Integration Server (HIS) |
Informations sur la version Oracle :
SQL Server prend en charge les scénarios hétérogènes suivants pour la réplication transactionnelle et par capture instantanée :
Publication de données à partir de SQL Server vers des Abonnés non-SQL Server.
La publication de données sur et depuis Oracle présente les restrictions suivantes :
| Réplication | Version 2016 ou antérieure | Version 2017 ou ultérieure |
|---|---|---|
| Réplication depuis Oracle | Prend uniquement en charge Oracle 10g ou une version antérieure | Prise en charge uniquement d’Oracle 10g ou des versions antérieures |
| Réplication vers Oracle | Jusqu’à Oracle 12c | Non pris en charge |
La réplication hétérogène vers les abonnés non-SQL Server est obsolète. Oracle Publishing est déprécié. Pour déplacer des données, créez des solutions en utilisant la capture de données de changement et le SSIS.
Pour plus d'informations sur la création d'abonnements à Oracle et IBM Db2, consultez Abonnés Oracle et Abonnés IBM Db2.
Considérations pour les abonnés non-SQL Server
Gardez à l’esprit les considérations suivantes lors de la réplication vers des abonnés non-SQL Server :
Considérations d’ordre général
La réplication supporte la publication de tables et de vues indexées sous forme de tables pour des abonnés non-SQL Server (les vues indexées ne peuvent pas être répliquées en tant que vues indexées).
Lorsque vous créez une publication dans l'Assistant de publication Nouvelle puis que vous l'activez pour les abonnés non-SQL Server en utilisant la boîte de dialogue Propriétés de publication, vous ne spécifiez pas le propriétaire de tous les objets dans la base de données d'abonnement pour les abonnés non-SQL Server. Pour les abonnés Microsoft SQL Server, le propriétaire est le propriétaire de l’objet correspondant dans la base de données de publication.
Si une publication compte à la fois des abonnés SQL Server et non-abonnés SQL Server, vous devez activer la publication pour les abonnés non-SQL Server avant de créer des abonnements à SQL Server Subscribers.
Par défaut, les scripts générés par l’Agent d'instantané pour les abonnés non-SQL Server utilisent des identifiants non cités dans la
CREATE TABLEsyntaxe. Par conséquent, un tableau publié nommétestest répliqué parTEST. Pour utiliser la même casse que celle de la table dans la base de données de publication, utilisez le paramètre -QuotedIdentifier de l’Agent de distribution. Vous devez également utiliser le paramètre -QuotedIdentifier si les noms d’objets publiés (tels que tables, colonnes et contraintes) contiennent des espaces ou des mots réservés dans la version de la base de données chez l’abonné non-SQL Server. Pour plus d'informations sur ce paramètre, consultez Agent de distribution de réplication.Le compte sous lequel s'exécute l'Agent de distribution doit disposer de droits d'accès au répertoire d'installation du fournisseur OLE DB.
Par défaut, pour les abonnés non-SQL Server, l’Agent Distribution utilise une valeur de
[(default destination)]pour la base de données d’abonnement (le paramètre -SubscriberDB pour l’Agent Distribution) :Pour Oracle, un serveur a au maximum une base de données, donc vous n’avez pas besoin de spécifier la base de données.
Pour IBM Db2, spécifiez la base de données dans la chaîne de connexion DB2. Pour plus d’informations, voir Créer un abonnement pour un Abonné non-SQL Server.
Si le serveur de distribution SQL Server est exécuté sur une plateforme 64 bits, vous devez utiliser la version 64 bits du fournisseur OLE DB approprié.
La réplication transfère les données au format Unicode, quels que soient l’interclassement ou les pages de code utilisés sur le serveur de publication et l’abonné. Choisissez une page de compilation ou de code compatible lors de la réplique entre éditeurs et abonnés.
Si vous ajoutez ou supprimez un article d’une publication, vous devez réinitialiser les abonnements aux abonnés non-SQL Server.
Les seules contraintes prises en charge pour tous les abonnés non-SQL Server sont :
NULLetNOT NULL. Les contraintes de clés primaires sont répliquées en tant qu'index uniques.Différentes bases de données traitent la valeur
NULLdifféremment. Cette différence influence la façon dont une valeur vide, une chaîne vide et unNULLa sont représentés. Cette différence affecte le comportement des valeurs insérées dans les colonnes avec des contraintes uniques définies. Par exemple, Oracle autorise plusieursNULLvaleurs dans une colonne considérée comme unique, tandis que SQL Server n’autorise qu’une seuleNULLvaleur dans une colonne unique.Un autre facteur est la façon dont
NULLles valeurs, chaînes vides et valeurs vides sont traitées lorsque la colonne est définie commeNOT NULL. Pour plus d'informations sur la résolution de ce problème pour les abonnés Oracle, consultez Abonnés Oracle.La réplication ne supprime pas les métadonnées liées à la réplication (table de séquence de transactions) des abonnés non-SQL Server lorsque vous supprimez l'abonnement.
Se conformer aux exigences de la base de données des abonnés.
Le schéma publié et les données doivent répondre aux exigences de la base de données de l’abonné. Par exemple, si une base de données non-SQL Server a une taille maximale de ligne plus petite que SQL Server, assurez-vous que le schéma et les données publiés ne dépassent pas cette taille.
Les tables répliquées vers des Abonnés autres que SQL Server adoptent les conventions de dénomination des tables de la base de données chez l’Abonné.
DDL n'est pas pris en charge par les abonnés non-SQL Server. Pour plus d’informations sur les modifications de schéma, consultez Modifier le schéma dans les bases de données de publication.
Prise en charge des fonctionnalités de réplication
SQL Server offre deux types d'abonnements : les abonnements par envoi de données (push) et les abonnements par extraction (pull). Les Abonnés non-SQL Server doivent utiliser les abonnements par envoi de données (push), dans lesquels l'Agent de distribution est exécuté sur le serveur de distribution SQL Server.
SQL Server offre deux formats de capture instantanée : le mode bcp natif et le mode caractère. Les Abonnés non-SQL Server nécessitent des instantanés en mode caractère.
Les abonnés non-SQL Server ne peuvent pas utiliser d'abonnements à mise à jour immédiate ou en file d'attente, ni être des nœuds dans une topologie pair-à-pair.
Les abonnés non-SQL Server ne peuvent pas être initialisés automatiquement à partir d'une sauvegarde.