Partager via

Considérations et limitations pour les éditeurs Oracle relatifs à la conception

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, vous devez connaître les limitations et problèmes suivants :

  • L’option Oracle Gateway offre des performances améliorées par rapport à l’option Oracle Complete ; Toutefois, cette option ne peut pas être utilisée pour publier la même table dans plusieurs publications transactionnelles. Une table peut apparaître dans au plus une publication transactionnelle et 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, d’index et de vues matérialisées. 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.

  • Il existe plusieurs différences dans la façon dont les fonctionnalités de réplication transactionnelle sont prises en charge lors de l’utilisation d’un serveur de publication Oracle.

Prise en charge de la publication d’objets à partir d’Oracle

La réplication prend en charge la réplication des objets suivants à partir de bases de données Oracle :

  • Tableaux

  • Tables organisées par index

  • Index

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

Les éléments suivants peuvent être présents sur les tables publiées, mais ne sont pas répliqués :

  • Index basés sur un domaine

  • Index basés sur des fonctions

  • Valeurs par défaut

  • Vérifier les contraintes

  • 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

  • Points de vue

  • 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 a 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.

  • Par défaut, les noms d’objets Oracle sont créés 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. L’échec de la spécification des objets dans le cas approprié peut entraîner un message d’erreur indiquant que l’objet est introuvable.

  • 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'objet volumineux (LOB) ne sont pas stockées dans la table du journal des articles ; les mises à jour des données d'objet volumineux sont toujours récupérées directement à partir de la table publiée. Les mises à jour sont répliquées dans des publications transactionnelles uniquement si l’opération affectant le métier déclenche le déclencheur de réplication sur la table répliquée. Les déclencheurs Oracle se déclenchent lorsque des lignes contenant des LOB sont insérées ou supprimées ; toutefois, les mises à jour des colonnes LOB ne déclenchent pas les déclencheurs. Une mise à jour d’une colonne métier est répliquée immédiatement uniquement si une colonne non métier de la même ligne est également mise à jour dans la même transaction Oracle. Si ce n’est pas le cas, la colonne LOB sera actualisée chez le réplicant lors de la prochaine mise à jour d’une colonne non-LOB dans la même ligne. Vérifiez que ce comportement est acceptable pour votre application.

Pour répliquer des mises à jour vers des colonnes LOB dans des publications transactionnelles, envisagez l’une des stratégies suivantes lorsque vous développez l'application :

  • Supprimez et réinsérez les lignes au sein d’une transaction au lieu de mettre à jour la ligne : spécifiez le nouveau LOB lors de la réinsère de la ligne. Étant donné que les actions de suppression et d'insertion déclenchent toutes deux des événements, 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 dans le cadre de la même transaction Oracle. Dans les deux cas, la mise à jour de la colonne non-LOB assure le déclenchement du déclencheur.

Pour plus d’informations sur les loB, consultez Data Type Mapping for Oracle Publishers.

Index et contraintes uniques

Pour la réplication d’instantané et transactionnelle, les colonnes contenues dans des index uniques et des contraintes (y compris les contraintes de clé primaire) doivent respecter certaines restrictions. S’ils ne respectent pas ces restrictions, la contrainte ou l’index ne sont pas répliqués.

  • 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 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.

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

  • Les colonnes impliquées dans des contraintes uniques ou des index ne doivent pas contenir de valeurs nulles.

Tenez également compte des problèmes 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 sur l’Abonné si la table publiée contient plusieurs lignes avec des valeurs NULL pour toutes les colonnes incluses dans l’index ou la contrainte.

  • Lorsqu'on teste l’unicité, les espaces de fin dans un champ de données 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 ne respecte pas les règles décrites dans les points précédents, 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 serviceées par le même serveur de distribution doivent chacune avoir 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 différée ; ou des topologies dans lesquelles les tables de publication servent aussi de tables d’abonnement, comme la réplication peer-to-peer et bidirectionnelle.

  • Les relations entre les clés primaires et les clés étrangères dans la base de données Oracle ne sont pas répliquées chez les souscripteurs. Toutefois, les relations sont conservées dans les données à mesure que les modifications sont apportées.

  • Les publications transactionnelles standard prennent en charge les tables de jusqu’à 1 000 colonnes. Les publications transactionnelles Oracle prennent en charge 995 colonnes (la réplication ajoute cinq colonnes à chaque table publiée).

  • Les clauses de tri sont ajoutées aux instructions CREATE TABLE afin de permettre des comparaisons sensibles à 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 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. Cela n’est pas pris en charge sur le serveur lié utilisé pour se connecter 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 Nouveau Abonnement fourni avec SQL Server 2005 et 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 aux Abonnés (valeur par défaut), sachez que la syntaxe MCALL est prise en charge, mais qu’elle a un comportement différent lorsque la publication provient d’un serveur de publication Oracle. En règle générale, MCALL fournit une carte de bits qui montre les colonnes qui ont été mises à jour chez l'Éditeur. Avec une publication Oracle, la bitmap montre toujours que toutes les colonnes ont été mises à jour. Pour plus d’informations sur l’utilisation de procédures stockées, consultez Spécifier comment les modifications sont propagées pour les 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 les publications SQL Server prennent en charge. 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 des abonnements de mise à jour immédiate ou de mise à jour en file d'attente, ou être des nœuds dans une topologie de type pair-à-pair ou bidirectionnelle.

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

  • SQL Server prend en charge deux types de validation : binaire et rowcount. Les serveurs de publication Oracle prennent en charge la validation du nombre de lignes. Pour plus d’informations, consultez Validation 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 captures instantanées en mode caractère.

  • Les modifications de schéma apportées aux tables Oracle publiées ne sont pas prises en charge. Pour apporter des modifications de schéma, supprimez d’abord la publication, apportez les modifications, puis recréez la publication et tous les abonnements.

    Remarque

    Si le schéma change et que la suppression et la recréation de la publication et des abonnements sont effectuées lorsque aucune activité n’a lieu sur les tables publiées, vous pouvez spécifier l’option « support de réplication uniquement » pour les abonnements. Cela leur permet d’être synchronisés sans avoir à copier un instantané sur chaque Abonné. Pour plus d’informations, consultez Initialiser un abonnement transactionnel sans instantané.

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

Le modèle de sécurité pour la publication Oracle est identique au modèle de sécurité pour la réplication transactionnelle standard, avec les exceptions suivantes :

Pour plus d’informations sur la sécurité de la réplication, consultez Sécurité de la réplication SQL Server.

Voir aussi

Considérations administratives pour les serveurs de publication Oracle
Configurer un serveur de publication Oracle
Vue d’ensemble de l’édition Oracle

  • Last updated on