• Article

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

En termes de conception, la publication à partir d'une base de données Oracle fonctionne de façon similaire à la publication à partir d'une base de données MicrosoftSQL 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 de capture instantanée 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 certaines différences mineures entre le stockage et le traitement des données effectués par Oracle et SQL Server qui ont une incidence sur 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

  • Valeurs par défaut

  • 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 Mappage de type de données pour les serveurs de publication Oracle.

Différences entre Oracle et SQL Server

  • Oracle présente des limites de taille maximale différentes pour certains objets. Tout objet créé dans la base de données de publication Oracle doit respecter les limites de taille maximale des objets correspondants dans SQL Server. Pour plus d'informations sur ces limites dans SQL Server, consultez Spécifications des capacités maximales pour SQL Server.

  • Les noms des objets Oracle sont créés par défaut en majuscules. Vérifiez que les noms des objets Oracle sont bien en majuscules lorsque vous les publiez via un serveur de distribution SQL Server s'ils figurent en majuscules dans 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 utilise une version du langage SQL légèrement différente de celle de SQL Server ; les filtres de lignes doivent être écrits dans une syntaxe compatible avec celle d'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 Mappage de type de données pour les serveurs de publication Oracle.

Contraintes et index uniques

Tant pour la réplication de capture instantanée 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é dans un index de SQL Server est 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 Mappage de type de données pour les serveurs de publication Oracle.

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

  • Lors de la vérification de l'unicité, les espaces à droite dans un champ sont ignorés par SQL Server mais pas par Oracle.

Comme c'est le cas dans la réplication transactionnelle SQL Server, les tables contenues dans les publications transactionnelles d'Oracle exigent une clé primaire, laquelle doit être unique en vertu des règles énoncé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 avoir le même nom que : son serveur de distribution SQL Server ; aucun des serveurs de publication SQL Server qui utilisent le serveur de distribution, ou aucun 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.

  • Un 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 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é par l'option de schéma 0x1000, spécifié 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 utilisez un Assistant pour créer un abonnement à une publication Oracle extrait (pull), vous devez utiliser l'Assistant Nouvel abonnement fourni avec SQL Server 2005 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 les abonnements aux publications Oracle extraits.

  • 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écification du 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 nombre de lignes. Les serveurs de publication Oracle prennent uniquement 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 de capture instantanée : le mode bcp natif et le mode caractères. Les serveurs de publication Oracle prennent en charge les captures instantanées 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.

    [!REMARQUE]

    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 une capture instantanée sur chaque Abonné. Pour plus d'informations, consultez Initialisation d'un abonnement transactionnel sans capture instantanée.

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 Sécurité et protection (réplication).