Oracle Golden Gate : Attention aux réplications bi-directionnelles

Avec GOLDEN GATE, l’outil phare de réplication de données en temps réel d’Oracle, il est possible de faire de la réplication de données entre différentes bases, de manière uni-directionnelle ou bi-directionnelle.
Dans le cas d’une réplication bi-directionnelle, il est important de veiller à ne pas entrer dans une réplication cyclique qui pourrait engendrer des problèmes de cohérences de données, et accessoirement des problèmes de performances également.
En effet, supposons que nous avons deux bases de données sur lesquelles nous souhaitons mettre en place une réplication bi-directionnelle :

Réplication bi-directionnelle

Pour cela, vous allez déclarer vos trails (extract et remote) sur chacun des environnements, et ceci pour chaque direction de flux.
Une fois le dispositif mis en place, il faut veiller à appliquer des filtres sur les conditions d’extraction des données d’une base à l’autre.
Explication par l’exemple
Supposons qu’une ligne est insérée dans la base DB1. Un mouvement de données est alors détecté dans les Archive/Redo logs de cette base. Cela déclenche la chaîne de réplication à travers les différents trails, comme le montre le schéma suivant :

Réplication bi-directionnelle

Une fois cette 1ère étape franchie, l’état des bases est cohérent et parfaitement synchronisé :

Réplication bi-directionnelle

En revanche, puisque la réplication est bi-directionnelle, elle s’applique donc dans les deux sens, et donc l’arrivée d’une donnée répliquée sur DB2 déclenche à son tour une réplication sur DB1 :

Réplication bi-directionnelle

Cette 3ème étape est une anomalie et ne doit pas se produire. Pour l’éviter, il faut ajouter un filtre dans le fichier de paramètres d’Extract de la base cible (DB2 dans ce cas de figure) :

TRANLOGOPTIONS EXCLUDEUSER <USERNAME>

Ceci permet d’exclure l’utilisateur mentionné dans la prise en compte des mouvements de données. Ainsi, dans notre cas, nous filtrerons sur l’utilisateur autorisé à venir écrire les réplications entrantes sur DB2, en l’occurrence GGS_OWNER :

TRANLOGOPTIONS EXCLUDEUSER GGS_OWNER

Par ce procédé, vous éviterez les réplications cycliques potentielles, pouvant mettre à mal la cohérence de votre système d’informations.
Important : il faut bien entendu appliquer ce filtre de part et d’autre des bases de données (dans les fichiers de paramètres d’Extract des deux environnements).

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *