Considérations de conception et limitations pour les éditeurs Oracle

S'applique à :SQL Server

Publier depuis une base de données Oracle fonctionne presque de la même manière que publier depuis une base de données Microsoft SQL Server. Cependant, soyez conscient des limitations et problèmes suivants :

  • L’option Oracle Gateway offre de meilleures performances que l’option Oracle Complete. Cependant, vous ne pouvez pas utiliser l’option Oracle Gateway pour publier la même table dans plusieurs publications transactionnelles. Un tableau ne peut apparaître que dans une seule publication transactionnelle mais peut apparaître dans un nombre quelconque de publications instantanées. Si vous devez publier la même table dans plusieurs publications transactionnelles, choisissez l'option Oracle Complete.

  • La réplication prend en charge la publication de tables, les index et les vues matérialisées. Il ne réplique pas d’autres objets.

  • Quelques petites différences entre le stockage et le traitement des données dans les bases de données Oracle et SQL Server influencent la réplication.

  • Il existe des différences dans la manière dont les fonctionnalités de réplication transactionnelle sont prises en charge lorsque vous utilisez un Oracle Publisher.

Prise en charge de la publication d’objets par Oracle

La réplication peut répliquer les objets de base de données Oracle suivants :

  • Tables

  • Tables organisées par index

  • Index

  • Vues matérialisées (reproduites sous forme de tableaux)

Les objets suivants peuvent apparaître sur les tables publiées mais ne sont pas répliqués :

  • Index basés sur les domaines

  • Index basés sur les fonctions

  • Valeurs par défaut

  • Contraintes de validation

  • Clés étrangères

  • Options de stockage (espaces de tables, clusters, etc.)

Les objets suivants ne peuvent pas être reproduits :

  • Tables imbriquées

  • Vues

  • Packages, corps de package, procédures et déclencheurs

  • Files d’attente

  • Séquences

  • Synonymes

Pour plus d'informations sur les types de données pris en charge, consultez Data Type Mapping for Oracle Publishers.

Différences entre Oracle et SQL Server

  • Oracle présente des limites de taille maximale différentes pour certains objets. Tous les objets que vous créez dans la base de données Oracle publication doivent respecter les limites de taille maximale pour les objets correspondants dans SQL Server. Pour plus d'informations sur les limites de SQL Server, voir Spécifications de capacité maximale pour SQL Server.

  • Par défaut, Oracle crée les noms d’objets en majuscules. Assurez-vous de fournir les noms des objets Oracle en majuscules lors de leur publication via un distributeur SQL Server s’ils sont en majuscules sur la base de données Oracle. Ne pas spécifier les objets dans le bon cas peut entraîner un message d’erreur indiquant que l’objet ne peut pas être trouvé.

  • Oracle utilise un dialecte SQL légèrement différent de SQL Server ; écrire des filtres de ligne dans une syntaxe conforme à Oracle.

Considérations pour les gros objets

La table de journalisation des articles ne stocke pas de données d’objet volumineux (LOB). Les mises à jour des données LOB sont toujours récupérées directement depuis la table publiée. Les mises à jour sont répliquées dans les publications transactionnelles dans le seul cas où l'opération affectant l'objet LOB active le déclencheur de réplication sur la table répliquée. Les déclencheurs d’Oracle s’activent lorsque des lignes contenant des LOB sont insérées ou supprimées. Cependant, les mises à jour des colonnes LOB ne déclenchent pas de déclencheurs. Une mise à jour d’une colonne LOB n’est immédiatement répliquée que si une colonne non-LOB de la même ligne est également mise à jour dans la même transaction Oracle. Sinon, la colonne LOB est rafraîchie au niveau de l’Abonné lors de la prochaine mise à jour d’une colonne non-LOB dans la même ligne. Assurez-vous que ce comportement est accepté par votre application.

Pour répliquer les mises à jour apportées aux colonnes LOB dans des publications transactionnelles, plusieurs stratégies sont possibles lorsque vous écrivez l'application :

  • Supprimez et réinsérez les lignes au sein d’une transaction au lieu de la mettre à jour : spécifiez le nouveau LOB lors de la réinsertion de la ligne. Comme la suppression et l’insertion déclenchent toutes deux des déclencheurs, la ligne est répliquée.

  • Incluez une colonne non LOB dans la mise à jour de ligne en plus de la colonne LOB ou mettez à jour une colonne non LOB de la ligne au cours de la même transaction Oracle. Dans les deux cas, la mise à jour de la colonne non LOB garantit l'activation du déclencheur.

Pour plus d'informations sur les objets volumineux, consultez Data Type Mapping for Oracle Publishers.

Index uniques et contraintes uniques

Tant pour la réplication d'instantané que transactionnelle, les colonnes contenues dans des index et des contraintes uniques (y compris les contraintes de clé primaire) doivent respecter certaines restrictions. S’ils ne respectent pas ces restrictions, la contrainte ou l’indice n’est pas reproduit.

  • Vous pouvez inclure jusqu’à 16 colonnes dans un index sur SQL Server.

  • Toutes les colonnes dans des contraintes uniques doivent avoir des types de données pris en charge. Pour plus d'informations sur les types de données, consultez Data Type Mapping for Oracle Publishers.

  • Vous devez publier toutes les colonnes dans des contraintes uniques (vous ne pouvez pas les filtrer).

  • Les colonnes dans des contraintes ou indices uniques ne devraient pas être nulles.

Veillez également à prendre en compte les points suivants :

  • Oracle et SQL Server traitent différemment la valeur NULL : Oracle autorise la présence de plusieurs lignes comportant des valeurs NULL pour les colonnes qui acceptent NULL et sont incluses dans des contraintes ou index uniques. SQL Server applique l'unicité en n'autorisant qu'une seule ligne contenant une valeur NULL pour la même colonne. Vous ne pouvez pas publier une contrainte ou un index unique qui autorise NULL car une violation de contrainte surviendrait sur l’Abonné si la table publiée contient plusieurs lignes avec des valeurs NULL pour n’importe quelle colonne incluse dans l’index ou la contrainte.

  • Lors de la vérification de l’unicité, SQL Server ignore les espaces en fin de champ, mais ce n’est pas le cas d’Oracle.

Comme dans la réplication transactionnelle SQL Server, les tables dans les publications transactionnelles Oracle nécessitent une clé primaire. La clé primaire doit être unique selon les règles spécifiées précédemment. Si la clé primaire ne suit pas ces règles, vous ne pouvez pas publier la table pour la réplication transactionnelle.

Différences entre la publication Oracle et la réplication transactionnelle standard

  • Un serveur de publication Oracle ne peut avoir le même nom que : son serveur de distribution SQL Server, l'un des serveurs de publication SQL Server qui utilisent le serveur de distribution ou l'un des Abonnés qui reçoivent la publication. Les publications traitées par le même serveur de distribution doivent avoir chacune un nom unique.

  • Une table publiée dans une publication Oracle ne peut pas recevoir de données répliquées. Par conséquent, la publication Oracle ne prend pas en charge les publications avec mise à jour immédiate ou les abonnements avec mise à jour en file d’attente, ni les topologies dans lesquelles les tables de publication servent également de tables d’abonnement, comme la réplication poste à poste et la réplication bidirectionnelle.

  • Les relations clé primaire-clé étrangère dans la base de données Oracle ne sont pas répliquées sur les Abonnés. Cependant, les relations sont préservées dans les données à mesure que les modifications sont appliquées.

  • Les publications transactionnelles standard prennent en charge des tables comprenant jusqu'à 1000 colonnes. Les publications transactionnelles Oracle prennent en charge 995 colonnes (la réplication ajoute cinq colonnes à chaque table publiée).

  • Des clauses COLLATE sont ajoutées aux instructions CREATE TABLE pour permettre l’exécution de comparaisons respectant la casse, ce qui est important pour les clés primaires et les contraintes uniques. Ce comportement est contrôlé par l’option de schéma 0x1000, spécifiée avec le paramètre @schema_option de sp_addarticle (Transact-SQL).

  • Si vous utilisez des procédures stockées pour configurer ou gérer un serveur de publication Oracle, ne placez pas les procédures dans une transaction explicite. L'opération n'est pas prise en charge sur le serveur lié utilisé pour la connexion au serveur de publication Oracle.

  • Si vous créez un abonnement par extraction à une publication Oracle à l’aide d’un Assistant, vous devez utiliser l’Assistant Nouvel abonnement fourni avec SQL Server 2005 (9.x) et les versions ultérieures. Pour les versions précédentes de SQL Server, vous pouvez en revanche utiliser la procédure stockée et les interfaces SQL-DMO pour configurer des abonnements pull aux publications Oracle.

  • Si vous utilisez des procédures stockées pour propager les modifications apportées aux Abonnés (option par défaut), sachez que la syntaxe MCALL est prise en charge mais se comporte différemment si la publication émane d'un serveur de publication Oracle. MCALL fournit habituellement un fichier bitmap qui montre les colonnes mises à jour sur le serveur de publication. Avec une publication Oracle, le fichier bitmap montre toujours toutes les colonnes mises à jour. Pour plus d’informations sur l’utilisation des procédures stockées, consultez Spécifier le mode de propagation des modifications des articles transactionnels.

Prise en charge des fonctionnalités de réplication transactionnelle

  • Les publications Oracle ne prennent pas en charge toutes les options de schéma que prennent en charge les publications de SQL Server. Pour plus d’informations sur les options de schéma, consultez sp_addarticle (Transact-SQL).

  • Les abonnés aux publications Oracle ne peuvent pas utiliser d’abonnements à mise à jour immédiate ou à mise à jour en file d’attente, ni être des nœuds dans une topologie pair-à-pair ou bidirectionnelle.

  • Les abonnés aux publications Oracle ne peuvent pas être automatiquement initialisés à partir d’une sauvegarde.

  • SQL Server prend en charge deux types de validation : binaire et nombre de lignes. Les éditeurs Oracle prennent en charge la validation du nombre de lignes. Pour plus d’informations, consultez Valider des données répliquées.

  • SQL Server offre deux formats d'instantanés : le mode BCP natif et le mode caractère. Les serveurs de publication Oracle prennent en charge les instantanés en mode caractères.

  • Les modifications de schéma des tables Oracle publiées ne sont pas prises en charge. Pour apporter des modifications au schéma, commencez par supprimer la publication, apportez vos modifications puis recréez la publication et les abonnements.

    Remarque

    Si vous effectuez des modifications de schéma et supprimez et recréez la publication et les abonnements lorsqu’aucune activité n’a lieu sur les tables publiées, vous pouvez spécifier l’option replication support only pour les abonnements. Cette option les synchronise sans copier un instantané à chaque abonné. Pour plus d’informations, consultez Initialiser un abonnement transactionnel sans instantané.

Modèle de sécurité de la réplication

Le modèle de sécurité de la réplication pour la publication Oracle est le même que celui de la réplication transactionnelle standard, à l’exception des exceptions suivantes :

Pour plus d’informations sur la sécurité de la réplication, consultez Afficher et modifier les paramètres de sécurité de la réplication.

Contenu connexe

  • Dernière mise à jour :