Oracle GoldenGate est une solution logiciel de type CDC (Change Data Capture) qui permet la collecte, le routage, la transformation et la livraison des données transactionnelles entre des environnements hétérogènes (IBM DB2, Microsoft SQL Server, MySQL, Sybase ASE, Teradata, etc..), en temps réel et avec un faible impact sur le système source.
Comme avec tous les outils CDC il peut y malheureusement se produire des problèmes de réplication dus à des erreurs SQL (ORA-00942, ORA-00001, ORA-01403, etc..).
Voyons comment se sortir de ces situations !

Trouver le SQL problématique parmi les milliers de transactions capturées est difficile.
Oui, il est possible de retrouver des  détails génériques en regardant dans le fichier « discard » ou avec logdump, mais une astuce pour voir exactement l’ordre des exécutions et tous les SQL complets est d’ajouter un deuxième extrait à la source et de sortir le format en SQL !
Dans l’exemple ci-dessous il y a un ORA-1400 pendant des batch replications.
voici l’information extraite par LOGDUMP :

GGSCI (goldengate2) >logdump:
 2010/09/12 22:58:28.014.681 Delete Len 202 RBA 1677964
 Name: DEST.TEST_ENTETE_DATE
 Before Image: Partition 4 G m
 0000 000b 0000 0007 3834 3732 3730 3800 0100 0600 | ........ 8472.....
 0000 0250 4600 0200 1600 0000 1233 3030 5846 4e20 | ...ORACLE........ 4370303 | 03994370303........40 …..

 
Toute cette information est utile mais c’est difficile de voir l’ordre des exécutions et tous les SQL complets. Il vaut mieux ajouter un deuxième extrait à la source et sortir le format en SQL
Voir ci-dessous:
Ajouter un nouveau « extract » SQL

GGSCI (goldengate1) > ADD EXTRACT EXTSQLFORMAT, TRANLOG, BEGIN NOW
 EXTRACT added.
GGSCI (goldengate1) > edit param EXTSQLFORMAT
  Extract ext1sql1
  USERID source, PASSWORD XXX
  Formatsql //Extrat format en SQL
  exttrail ./dirdat/ext1sql1 //localisation de fichier SQL
  table source.*; //schema a rechercher
GGSCI (goldengate1) >ADD EXTTRAIL  ./dirdat/extsqlf , EXTRACT EXTSQLF
GGSCI (goldengate1) >start EXTSQLF

Maintenant il faut juste analyser le SQL pour trouver l’erreur:

[oracle@goldengate1 dirdat]$ ls -lsrt
rw-rw-rw- 1 oracle oinstall 5603 Jun 13 03:50 ext1sql1000000
rw-rw-rw- 1 oracle oinstall 1132 Jun 13 03:51 et000056
[oracle@goldengate1 dirdat]$ cat ext1sql1000000
INSERT INTO SOURCE.TEST_ENTETE_DATE (CUST_CODE,SOCIETE, REFERENCE, )
     VALUES ('8472','ORACLE.','03994370303','40') ;
C,2011-06-13:08:24:51.000000,1307978656,412,
INSERT INTO SOURCE.TEST_ENTETE_DATE (CUST_CODE,SOCIETE, REFERENCE, ) 
 VALUES ('8472','ORACLE.','4370303',NULL);
ORA-1400 B,2011-06-13:08:24:52.000000,1307978692,412,
DELETE FROM SOURCE.COPY_TCUSTMER WHERE CUST_CODE='JANE';

Beaucoup plus lisible, non ?