Problèmes et limitations de conception des serveurs de publication Oracle

  • Article

S’applique à :SQL Server

La publication à partir d’une base de données Oracle est conçue pour fonctionner de façon presque identique à la publication à partir d’une base de données Microsoft SQL Server. Toutefois, soyez conscient des problèmes et limitations suivants :

  • L'option Oracle Gateway offre de meilleures performances que l'option Oracle Complete ; il n'est cependant pas possible de l'utiliser pour publier la même table dans plusieurs publications transactionnelles. Une table peut faire partie d'un nombre quelconque de publications d'instantané mais d'une seule publication transactionnelle uniquement. Si vous devez publier la même table dans plusieurs publications transactionnelles, choisissez l'option Oracle Complete.

  • La réplication prend en charge les vues matérialisées, les index et les tables de publication. Les autres objets ne sont pas répliqués.

  • Il existe quelques petites différences entre le stockage et le traitement des données dans les bases de données Oracle et SQL Server qui affectent la réplication.

  • Le mode de prise en charge des fonctionnalités de réplication transactionnelle diffère quelque peu lorsque vous utilisez un serveur de publication Oracle.

Prise en charge des objets de publication d'Oracle

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

  • Tables

  • Tables indexées

  • Index

  • Vues matérialisées (répliquées en tant que tables)

Les éléments suivants peuvent figurer dans les tables publiées mais ne sont pas répliqués :

  • Index basés sur les domaines

  • Index basés sur les fonctions

  • Defaults

  • Contraintes de validation

  • Clés étrangères

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

Les objets suivants ne peuvent pas être répliqués :

  • 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 créés dans la base de données de publication Oracle doivent respecter les limites de taille maximale pour les objets correspondants dans SQL Server. Pour plus d’informations sur les limites dans SQL Server, consultez Spécifications de capacité maximale pour SQL Server.

  • Les noms des objets Oracle sont créés par défaut en majuscules. Veillez à fournir les noms des objets Oracle en majuscules lors de leur publication via un serveur de distribution SQL Server s’ils sont en majuscules sur la base de données Oracle. Si vous ne respectez pas la casse, il se peut qu'un message d'erreur indiquant que l'objet est introuvable s'affiche.

  • Oracle a un dialecte SQL légèrement différent de SQL Server ; Les filtres de lignes doivent être écrits dans la syntaxe conforme à Oracle.

Considérations relatives aux objets volumineux

Les données d'objets volumineux (LOB, Large Object) ne sont pas stockées dans la table du journal d'articles ; les mises à jour de ces données sont toujours directement extraites de 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 Oracle sont activés lorsque des lignes contenant des objets LOB sont insérées ou supprimées. En revanche les mises à jour apportées aux colonnes LOB n'activent pas les déclencheurs. La mise à jour d'une colonne LOB est répliquée immédiatement uniquement 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 actualisée sur l'Abonné lors de la mise à jour suivante 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 la ou les lignes dans une transaction au lieu de mettre à jour la ligne : spécifiez le nouvel objet LOB lors de la réinsertion de la ligne. Dans la mesure où les opérations de suppression et d'insertion activent toutes deux les déclencheurs, la ligne sera 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.

Contraintes et index 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. Si ce n'est pas le cas, la contrainte ou l'index n'est pas répliqué.

  • Le nombre maximal de colonnes autorisées dans un index sur SQL Server est de 16.

  • Toutes les colonnes incluses dans des contraintes uniques doivent contenir 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.

  • Toutes les colonnes incluses dans des contraintes uniques doivent être publiées (elles ne peuvent pas être filtrées).

  • Les colonnes contenues dans des contraintes ou des index uniques ne doivent pas être Null.

Veillez également à prendre en compte les points suivants :

  • Oracle et SQL Server traitent NULL différemment : Oracle autorise plusieurs lignes avec des valeurs NULL pour les colonnes qui autorisent NULL et sont incluses dans des contraintes ou des index uniques. SQL Server applique l’unicité en autorisant uniquement une seule ligne avec 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 se produit au niveau de l'Abonné si la table publiée contient plusieurs lignes avec des valeurs NULL pour l'une des colonnes incluses dans l'index ou la contrainte.

  • Lorsque vous testez l’unicité, les espaces de fin dans un champ sont ignorés par SQL Server, mais pas par Oracle.

Comme dans la réplication transactionnelle SQL Server, les tables des publications transactionnelles Oracle nécessitent une clé primaire ; la clé primaire doit être unique en fonction des règles spécifiées ci-dessus. Si la clé primaire n'adhère pas aux règles définies ci-dessus, la table ne peut pas être publiée pour la réplication transactionnelle.

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

  • Un serveur de publication Oracle ne peut pas avoir le même nom que : son serveur de distribution SQL Server ; les serveurs de publication SQL Server qui utilisent le serveur de distribution ; ou tous les 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 abonnements mis à jour en attente, ou les topologies dans lesquelles les tables de publication servent également de tables d'abonnement, comme la réplication d'égal à égal 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. En revanche, les relations sont conservées dans les données au moment de la remise des modifications.

  • 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é avec l’option de schéma 0x1000, qui est spécifiée avec le @schema_option paramètre 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 vers une publication Oracle avec 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 toutefois utiliser la procédure stockée et les interfaces SQL-DMO pour configurer des abonnements par extraction vers des 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 de la fonctionnalité de réplication transactionnelle

  • Les publications Oracle ne prennent pas en charge toutes les options de schéma prises en charge par les publications 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 les abonnements mis à jour immédiatement ou en attente ou être des nœuds dans une topologie d'égal à égal 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 rowcount. Les serveurs de publication Oracle prennent uniquement en charge la validation du nombre de lignes. Pour plus d’informations, consultez Valider des données répliquées.

  • SQL Server propose deux formats d’instantané : 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 apportées aux 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.

    Note

    Si les modifications du schéma ainsi que la suppression et recréation ultérieures de la publication et des abonnements sont effectuées à un moment où il n'y a aucune activité sur les tables publiées, vous pouvez spécifier l'option « Prise en charge de la réplication uniquement » pour les abonnements. Ils peuvent ainsi être synchronisés sans devoir copier un instantané sur 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é pour la publication Oracle est identique à celui de la réplication transactionnelle standard, à ces différences près :

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.

Voir aussi

Considérations sur l’administration des serveurs de publication Oracle
Configurer un serveur de publication Oracle
Vue d’ensemble de la publication Oracle