Pour les adeptes de la réplication goldengate qui utilisent le produit goldengate veridata pour contrôler l’état de synchronisation des bases , voila une excellente nouvelle concernant la version 12c.
Jusqu’à présent le logiciel veridata 11g se contentait de comparer les données et d’identifier les écarts entre la base source et la base cible. On pouvait aussi, avec un fichier xml et en maitrisant un peu le perl, le python ou le shell, générer un script sql qui pouvait resynchroniser les tables. Mais ce processus restait lourd et fastidieux.
Aujourd’hui et grâce à la version 12.1.3, cette opération de resynchronisation des bases est rendue simple, automatique et complètement intégrée à l’outil.
L’installation du produit veridata est très simple et nécessite dans l’ordre l’installation des composants suivants :
- Une version JDK (et non JRE) 1.7
- Oracle Fusion Middleware Infrastructure 12c ( inclut Oracle WebLogic Server, Oracle Coherence, et Oracle JRF infrastructure services)
- Une base Oracle (qui servira de référentiel à veridata) de préférence avec AL32UTF8 comme jeu de caractères.
- Le paquet goldengate veridata 12.1.3
Une fois ces composants installés, il suffit dans l’interface d’administration weblogic de créer un compte dédié veridata et de lui affecter tous les privilèges pour être sur de bénéficier de toutes les nouvelles fonctionnalités offertes par veridata 12c.
URL de l’interface d’administration weblogic : http://hostname:7001/console
–> domaines de sécurité –> myrealm –> utilisateurs et groupes
Une fois connecté dans l’interface graphique veridata via l’URL http://hostname:8830/veridata/ , le bouton « REPAIR » apparaitra dorénavant pour vous permettre de corriger les écarts de synchronisation des tables.
Un simple clic sur le bouton « Repair » , et veridata fera le nécessaire pour resynchroniser les tables ayant le status Out-Of-Sync. Vous pourrez même préciser la ou les table(s) sur lesquelles vous souhaitez exécuter l’opération.
Cette nouveauté de la version 12c va probablement attirer les clients qui aujourd’hui rencontrent souvent des cas de désynchronisations de tables et passent beaucoup de temps à réajuster ces écarts (duplicate rman , export/import ou initial load).
La resynchronisation de tables gérée par goldengate veridata 12c peut ne pas fonctionner correctement dans les cas suivants :
- La réplication bidirectionnelle
- Les tables complétement démunies d’index
L’idéal est donc d’utiliser l’outil sur des environnements ou la réplication s’effectue toujours d’une base vers une autre et portant sur des tables indexées (de préférence clé primaire ou unique), ce qui correspond à une très grande majorité des environnements où goldengate est aujourd’hui utilisé.
