Abonnés non-SQL Server

Les abonnés non-SQL Server suivants peuvent s’abonner à des publications instantanées et transactionnelles avec des abonnements push. Les abonnements sont pris en charge pour les deux versions les plus récentes de chaque base de données répertoriée à l’aide de la version la plus récente du fournisseur OLE DB répertoriée.

La réplication hétérogène vers les abonnés non-SQL Server est déconseillée. La publication Oracle est déconseillée. Pour déplacer des données, créez des solutions à l’aide de la capture de données modifiées et de 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 relatives aux 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 prend en charge la publication de tables et de vues indexées en tant que tables auprès d'abonnés de systèmes autres que SQL Server (les vues indexées ne peuvent pas être répliquées en tant que vues indexées).

• Lors de la création d’une publication dans l’Assistant Nouvelle publication, puis en l’activant pour les abonnés non-SQL Server à l’aide de la boîte de dialogue Propriétés de publication, le propriétaire de tous les objets de la base de données d’abonnement n’est pas spécifié pour les abonnés non-SQL Server, tandis que pour les abonnés Microsoft SQL Server, il est défini sur le propriétaire de l’objet correspondant dans la base de données de publication.

• Si une publication aura des abonnés SQL Server et des abonnés non-SQL Server, la publication doit être activée pour les abonnés non-SQL Server avant la création d’abonnements aux abonnés SQL Server.

• Par défaut, les scripts générés par l'Agent d'instantané pour les abonnés utilisant des systèmes autres que SQL Server emploient des identificateurs sans guillemets dans la syntaxe « CREATE TABLE ». Par conséquent, une table publiée nommée « test » est répliquée sous le nom de « TEST ». Pour utiliser le même cas que la table de la base de données de publication, utilisez le paramètre -QuotedIdentifier pour l’Agent de distribution. Le paramètre -QuotedIdentifier doit également être utilisé si les noms d’objets publiés (tels que les tables, les colonnes et les contraintes) incluent des espaces ou des mots réservés dans la version de la base de données sur l’Abonné non-SQL Server. Pour plus d’informations sur ce paramètre, consultez l’Agent de distribution de réplication.

• Le compte sous lequel l’Agent de distribution s’exécute doit avoir un accès en lecture au répertoire d’installation du fournisseur OLE DB.

• Par défaut, pour les abonnés non-SQL Server, l’Agent de distribution utilise une valeur [(destination par défaut)] pour la base de données d’abonnement (paramètre -SubscriberDB pour l’Agent de distribution) :

  • Pour Oracle, un serveur possède au plus une base de données. Il n’est donc pas nécessaire de spécifier la base de données.

  • Pour IBM DB2, la base de données est spécifiée dans la chaîne de connexion DB2. Pour plus d’informations, consultez Créer un abonnement pour un abonné non-SQL Server.

• Si le serveur de distribution SQL Server s’exécute sur une plateforme 64 bits, vous devez utiliser la version 64 bits du fournisseur OLE DB approprié.

• La réplication déplace les données au format Unicode, quelle que soit la collation/les pages de code utilisées sur l'Éditeur et l'Abonné. Il est recommandé de choisir une page de classement/de codes compatible lors de la réplication entre les serveurs de publication et les abonnés.

• Si un article est ajouté ou supprimé d’une publication, les abonnements aux abonnés non-SQL Server doivent être réinitialisés.

• Les seules contraintes prises en charge pour tous les abonnés non-SQL Server sont les suivantes : NULL et NOT NULL. Les contraintes de clé primaire sont répliquées en tant qu’index uniques.

• La valeur NULL est traitée différemment par différentes bases de données, ce qui affecte la façon dont une valeur vide, une chaîne vide et une valeur NULL sont représentées. Cela affecte à son tour le comportement des valeurs insérées dans des colonnes avec des contraintes uniques définies. Par exemple, Oracle autorise plusieurs valeurs NULL dans une colonne considérées comme uniques, tandis que SQL Server n’autorise qu’une seule valeur NULL dans une colonne unique.

  Un facteur supplémentaire est la façon dont les valeurs NULL, les chaînes vides et les valeurs vides sont traitées lorsque la colonne est définie comme NOT NULL. Pour plus d’informations sur la résolution de ce problème pour les abonnés Oracle, consultez Abonnés Oracle.

• Les métadonnées liées à la réplication (table de séquence de transactions) ne sont pas supprimées des abonnés non-SQL Server lorsque l’abonnement est supprimé.

Conformité aux exigences de la base de données de l’Abonné

• Le schéma et les données publiés doivent être conformes aux exigences de la base de données sur l’Abonné. Par exemple, si une base de données non-SQL Server a une taille de ligne maximale inférieure à SQL Server, vous devez vous assurer 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 non-SQL Server adoptent les conventions d’affectation de noms de table de la base de données sur l’Abonné.

• DDL n’est pas pris en charge pour les abonnés non-SQL Server. Pour plus d’informations sur les modifications de schéma, consultez Apporter des modifications de schéma sur les bases de données de publication.

Prise en charge des fonctionnalités de réplication

• SQL Server offre deux types d’abonnements : push et pull. Les abonnés non-SQL Server doivent utiliser des abonnements Push, dans lesquels l’Agent de distribution s’exécute sur le serveur de distribution SQL Server.

• SQL Server propose deux formats d’instantané : le mode bcp natif et le mode caractère. Les abonnés non-SQL Server nécessitent des captures instantanées en mode caractère.

• Les abonnés non-SQL Server ne peuvent pas utiliser des 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.

Voir aussi

Réplication de base de données hétérogène
S’abonner aux Publications