Cet article traite de la nécessité d’activer les SUPPLEMENTAL LOG sur les tables faisant l’objet d’une réplication avec goldengate pour avoir la garantie d’une réplication robuste et fiable en toutes circonstances. Il fournit également des informations utiles pour activer le « bon niveau » de SUPPLEMENTAL LOG.

 

Pourquoi faut il activer ces SUPPLEMENTAL LOGS avec Oracle goldengate ?

1.  Tout d’abord parce qu’en l’absence d’activation minimale de ces SUPPLEMENTAL LOGS , goldengate refusera de démarrer son process de capture des transactions sur la base source.
 
 
Vous verrez apparaitre au démarrage du process un message d’erreur du style :

ERROR   OGG-00717 Found unsupported in-memory undo record in sequence 123
, at RBA 123456, with SCN 1.2345678 (123456) ... Minimum supplemental logging must be enabled.

Pour activer ce niveau minimum d’informations supplémentaires dans les fichiers de redologs, il vous suffit d’exécuter la commande suivante :

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA ;

Il vous faudra ensuite relancer le process de capture qui pourra alors exploiter le contenu des logs incluant cette fois les informations supplémentaires dont goldengate a besoin pour effectuer correctement sa réplication.

ggsci> alter extract <process_de_capture> begin now
ggsci> start extract <process_de_capture>

Ne pas oublier également de réinitialiser la base cible qui du coup ne pourra plus être synchrone avec la base source.
 
2. Le niveau minimum de SUPPLEMENTAL LOGS (commande ALTER DATABASE ADD SUPPEMENTAL LOG DATA) bien que nécessaire à la réplication, n’est pas toujours suffisant, notamment dans les cas de figure ou oracle ne parvient pas sur la cible à identifier de façon unique l’enregistrement à modifier  (ex: UPDATE sur une table complétement démunie d’indexes, ou un UPDATE sur une colonne faisant partie d’un index).
Ce cas de figure est assez fréquent, et se traduit généralement par la remontée d’erreur ORA-01403 (no data found) qui fait planter le process goldengate (REPLICAT en statut ABENDED).
Attention  : l’erreur ORA-01403 ne remonte pas si vous avez utilisée la clause HANDLECOLLISIONS dans le fichier de configuration du process REPLICAT  goldengate.
Cette clause HANDLECOLLISIONS n’est à utiliser que lorsque vous effectuez des chargements directs de tables en parallèle de la réplication et considère que les erreurs de type ORA-01403 ou ORA-00001 sont « normales », car gérées par ailleurs.
 

Comment activer le « bon niveau » de SUPPLEMENTAL LOG ?

Pour y parvenir, plusieurs solutions sont à votre disposition. à vous de choisir la mieux adaptée à votre environnement en fonction de la volumétrie de vos redologs et de la version de vos bases de données.

Solution 1 –   Activation des SUPPLEMENTAL LOGS  au niveau de la base

ALTER DATABASE ADD SUPPLEMENTAL LOG ..

En plus du niveau minimum requis pour la réplication, on peut ajouter dans les redologs des informations supplémentaires concernant :
a) Les colonnes de la clé primaire : DATA (PRIMARY KEY) COLUMNS
b) Les colonnes d’une clé unique :  DATA (UNIQUE INDEX) COLUMNS
c) Les colonnes d’une clé étrangère :  DATA (FOREIGN KEY) COLUMNS
d) Toutes les colonnes de la table :  DATA (ALL) COLUMNS
e) Une combinaison des options précédentes (ex:  DATA (PRIMARY KEY,UNIQUE INDEX,ALL) COLUMNS)

avantages:

• toute création de nouvelle table au niveau de la base héritera naturellement de ces ajouts d’informations dans les redologs.

inconvénients:

• la volumétrie des redologs peut être conséquente surtout si l’on ne réplique qu’une petite partie de la base de données (quelques schémas ou quelques tables).

Solution 2 – Activation des SUPPLEMENTAL LOGS  au niveau de la table

On utilise les mêmes commandes que précédemment mais cette fois uniquement  au niveau des tables qui font l’objet de la réplication.

ALTER TABLE <table> ADD SUPPLEMENTAL LOG ...
ex: ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY,UNIQUE INDEX) COLUMNS ;

avantages :

• nécessite moins de volumétrie dans les redologs (par rapport à la solution 1) surtout lorsque peu de tables sont à répliquer.

inconvénients:

• n’est pas dynamique par rapport aux évolutions de la table (ex: ajout ou suppression de clés) ou de la base (ex: création d’une nouvelle table)
• toute nouvelle création de table doit faire l’objet d’une activation des logs (commande ALTER TABLE … ADD SUPPLEMENTAL LOG DATA …)

Solution 3 – activation des SUPPLEMENTAL LOGS  avec la commande ADD TRANDATA

Cette commande goldengate est à exécuter dans l’outil ggsci.

ggsci> add trandata <schema>.<table>  (pour une seule table)
  Ou
ggsci> add trandata <schema>.*  (pour l'ensemble des tables d'un schéma)

Avantages:

• Goldengate va optimiser au mieux la volumétrie des informations ajoutées dans les redologs en n’y ajoutant que les colonnes de la clé primaire, ou celles d’une clé unique ou au pire toutes les colonnes de la table si celle-ci est démunie de clés.
• Goldengate va automatiquement mettre à jour les informations ajoutées aux redologs si le plan d’indexation de la table venait à changer (ajout de clé unique , suppression ou modification de la clé primaire,etc…)
• Goldengate va générer des commandes SQL (ALTER TABLE .. ADD SUPPLEMENTAL LOG GROUP …) qui permettront d’alimenter les vues DBA_LOG_GROUPS et DBA_LOG_GROUP_COLUMNS , ce qui permet de  visualiser aisément les informations ajoutées dans les redologs. ces informations peuvent également être consultées via l’outil ggsci en exécutant la commande INFO TRANDATA.

Inconvénients:

• En cas d’ajout de tables sur la base source , ces dernières ne pourront pas bénéficier des ajouts d’informations dans les redologs, sauf si l’on spécifie dans le fichier de paramètres goldengate la clause DDLOPTIONS ADDTRANDATA.

Solution 4 – Activation des SUPPLEMENTAL LOGS avec  la commande ADD SCHEMATRANDATA

Toujours via l’outil ggsci , cette commande se passe de la manière suivante :

ggsci> add schematrandata <nom du schéma>

Avantages:

• Gère les notions d’héritage au sein du schéma. Autrement dit, toute création de nouvelle table dans le schéma concerné se verra automatiquement attacher les informations supplémentaires de colonnes dans les redologs.
• goldengate va automatiquement exécuter des packages de type  DBMS_xxxx pour alimenter les vues DBA_CAPTURE_PREPARED_SCHEMAS et/ou DBA_CAPTURE_PREPARED_TABLES…. Et oui, pour les nostalgiques d’Oracle Streams, goldengate va bel et bien solliciter les packages d’Oracle streams pour sa réplication !!!

Inconvénients:

• Consomme un peu plus de volumétrie que la solution ADD TRANDATA au niveau des redologs, car elle ajoute beaucoup plus d’informations pour les tables munies de plusieurs clés.

ex: dans le cas d’une table munie d’une clé primaire et de plusieurs clés uniques, la commande ADD SCHEMATRANDATA va ajouter dans les redologs le détail des colonnes de l’ensemble de ces clés, même si le contenu de ces colonnes n’a pas été modifié sur la base source.

• Cette commande SCHEMATRANDATA ne fonctionne bien qu’à partir de la version goldengate 12.1 et avec certaines restrictions du coté version database (voir MOS 1426440.1).

 

Alors finalement ,quelle solution adopter ?

Pour la grande majorité des cas de figure et par expérience, la solution 3 (ADD TRANDATA) reste aujourd’hui celle qui donne les meilleurs résultats en termes de fiabilité ,volumétrie, suivi et performances …et ce quelque soient les versions d’Oracle et de Goldengate utilisées .
A noter toutefois, qu’Oracle recommande de plus en plus l’usage de la commande ADD SCHEMATRANDATA qui offre d’avantage de souplesse (par rapport à la commande ADD TRANDATA), mais comporte encore à ce jour trop de restrictions quant au choix des versions de composants utilisés.