GoldenGate est le nouvel outil Oracle pour apporter l’intégration des données temps réelle aux masses. Et de fait, le sujet est « red hot » ! Loin de moi l’ambition de couvrir un sujet aussi intéressant que les data warehouses temps réel, les mises à jour à chaud ou la continuité, mais de fait, le champ des applications est très large et l’offre, désormais partie Intégrante de Fusion Middleware Integration, complète parfaitement ODI.

Parmi les avantages d’Oracle GoldenGate, on peut citer:

• Sa capacité à exploiter des données en provenance et à destination de tous les SGBDR du marché de MySQL à Teradata en passant par SQL*Server, DB2 Mainframe ou Oracle SE1
• Une grande simplicité de mise en oeuvre comme vous allez pouvoir le découvrir
• Un vaste ensemble d’outils pour gérer la supervision ou le rapprochement des données

Cet article est une très succincte introduction technique à GoldenGate, il n’a pas d’autre ambition que de vous aider à construire votre GoldenGate « Hello World ».

Architecture

Vous l’aurez compris GoldenGate est une architecture distribuée avec des composants sur des serveurs de types différents et interagissant avec des bases de données différentes. Dans notre exemple, nous allons utiliser une seule instance GoldenGate pour répliquer dans un sens uniquement les données de la table SCOTT.DEPT dans la table DEMO.DEPT; la solution finale que nous obtiendrons ressemblera à celle ci-dessous:
Les composants en jeu sont les suivants:

• L’extract collecte les changements dans les redologs et archivelogs de la base de données Oracle et les envoie au Manager. A noter que ce process doit se connecter à la base de données pour non seulement collecter l’emplacement des logs mais également pour connaitre les identifiants des objets dans les logs et pour extraire certaines données (types LOB, UDT…) de la base de données.
• Le manager stocke les vecteurs de changement dans les fichiers TRAIL. Vous pouvez visialiser ces fichiers avec l’utilitaire GoldenGate logdump
• Le replicat récupère les changements dans les fichiers TRAIL et les applique dans la base de données

A fond sur Koala

Puisque mon portable fonctionne sur Karmic Koala, j’ai décidé de tester GoldenGate avec Oracle 11g Release 2 (aka 11gR2) sur Ubuntu 9.10. Bien sur, ce n’est pas supporté mais, il ne s’agit que de tests et je n’ai pas rencontré de problèmes jusqu’à présent; ne faites pas ça en production ;-). J’ai téléchargé et installé GoldenGate depuis Oracle E-Delivery puisque la version Linux x86 n’est pas disponible sur Oracle Technology Network. J’ai choisi la distribution ci-dessous :

• Select a product Pack: « Oracle Fusion Middleware »
• Platform: « Linux x86 »
• Description: « Oracle GoldenGate on Oracle Media Pack for Linux x86 »
• Name: « Oracle GoldenGate V10.4.0.x for Oracle 11g on RedHat 5.0 »

Pour effectuer l’installation, il suffit de dézipper et dé-tar-er le fichier dans le répertoire de votre choix, positionner l’environnement pour accéder à la base de données Oracle et c’est tout; n’importe qui peut installer Oracle sur Ubuntu de toute façon :

. oraenv
ORACLE_SID = [WHITE] ? BLACK
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle

Et voilà, c’est fini; vous pouvez lancer l’interface ligne de commande de GoldenGate:

./ggsci 

Oracle GoldenGate Command Interpreter for Oracle
Version 10.4.0.19 Build 002
Linux, x86, 32bit (optimized), Oracle 11 on Sep 29 2009 08:50:50

Copyright (C) 1995, 2009, Oracle and/or its affiliates.  All rights reserved.

exit

Préparer la base de données

Il y a plusieurs pré-requis à vérifier sur la base de données utilisée pour effectuer la capture. Elle doit être en archivelog et GoldenGate doit pouvoir accéder aux journaux :

sqlplus / as sysdba

archive log list
Database log mode        Archive Mode
Automatic archival        Enabled
Archive destination        /u01/app/oracle/oradata/BLACK/archivelogs
Oldest online log sequence     1
Next log sequence to archive   3
Current log sequence        3

Il faut positionner NLS_LANG pour qu’il corresponde au paramétrage de la la base de données :

sqlplus / as sysdba

select parameter, value
  from nls_database_parameters
 where parameter in ('NLS_LANGUAGE',
                     'NLS_TERRITORY',
                     'NLS_CHARACTERSET',
                     'NLS_LENGTH_SEMANTICS');

parameter            VALUE
-------------------- -------------
NLS_LANGUAGE         AMERICAN
NLS_TERRITORY        AMERICA
NLS_CHARACTERSET     WE8MSWIN1252
NLS_LENGTH_SEMANTICS BYTE

exit

export NLS_LANG=AMERICAN_AMERICA.WE8MSWIN1252

La configuration s’appuie sur un utilisateur avec un niveau de privilège élevé. Il doit en effet pouvoir récupérer les identifiants des objets dans les redologs ou effectuer des requêtes « flashback » pour récupérer les valeurs des UDT ou des LOB qui va chercher directement sur la base de données source. Il doit être capable d’activer les groupes de journalisations supplémentaires sur les tables :

sqlplus / as sysdba

create user gg
  identified by gg
  default tablespace users
  temporary tablespace temp;

grant create session, resource, dba to gg;

La base de données doit également avoir le niveau minimum de « supplemental log » activé :

alter database add supplemental log data;

alter system switch logfile;

Dans mon cas, c’était tout! Évidemment, selon ce que vous cherchez à faire, il se peut que vous ayez besoin de plus de paramétrages sur la base de données source ou la base de données cible. Il se peut que vous ayez besoin de tables pour auditer les ordres DDL ou pour stocker les checkpoints sur la cible. Pour une liste complète de ce qu’il est nécessaire d’effectuer, référez-vous à la documentation GoldenGate et plus particulièrement à « Oracle Installation and Setup Guide ».

Le schéma DEMO

Comme discuté, cet article ne vise pas à effectuer une quelconque configuration avancée. Je veux juste répliquer la table scott.dept dans le schéma demo. Pour rendre l’exemple encore plus simple, je vais considérer que personne n’accède la table pendant la configuration et je ne ferai pas attention aux transactions en cours sur la table ou si les objets ne sont pas synchronisés. Je vous propose de simplement créer la table demo.dept et de charger les données de scott.dept dedans :

create user demo identified by demo
       default tablespace users
       temporary tablespace temp
       quota unlimited on users;

grant connect, resource to demo;

create table demo.dept
            ( deptno number(2,0),
              dname  varchar2(14),
              loc    varchar2(13),
              constraint pk_dept primary key(deptno))
  tablespace users;

insert into demo.dept
   select * from scott.dept;

commit;

Configurer le Manager GoldenGate

Une fois la base de données configurée, reportez-vous au document « Administration Guide » pour continuer et connaitre les détails
de la configuration de GoldenGate. D’abord, il faut créer tous les répertoires pour stocker les éléments de configuration, les journaux et les fichiers trails. Vous pouvez, là encore, choisir des destinations alternatives mais ce n’est pas vraiment notre préoccupation du moment:

./ggsci 

create subdirs

Creating subdirectories under current directory /gg

Parameter files                /gg/dirprm: created
Report files                   /gg/dirrpt: created
Checkpoint files               /gg/dirchk: created
Process status files           /gg/dirpcs: created
SQL script files               /gg/dirsql: created
Database definitions files     /gg/dirdef: created
Extract data files             /gg/dirdat: created
Temporary files                /gg/dirtmp: created
Veridata files                 /gg/dirver: created
Veridata Lock files            /gg/dirver/lock: created
Veridata Out-Of-Sync files     /gg/dirver/oos: created
Veridata Out-Of-Sync XML files /gg/dirver/oosxml: created
Veridata Parameter files       /gg/dirver/params: created
Veridata Report files          /gg/dirver/report: created
Veridata Status files          /gg/dirver/status: created
Veridata Trace files           /gg/dirver/trace: created
Stdout files                   /gg/dirout: created

Une fois l’opération précédente effectuée, éditez le fichier de configuration du manager et positionnez le paramètre port. le fichier de configuration s’appelle MGR ; une fois l’opération effectuée, vous pouvez démarrer le manager :

edit params mgr

view params mgr
port 7809

start manager

status manager
Manager is running (IP port arkzoyd.7809).

Ajouter un group de journalisation supplémentaire à la table source

Comme pour Oracle Streams (pas de secret!), GoldenGate a besoin d’identifier la ligne sur laquelle les changements sont appliqués sans utiliser le ROWID. Il existe des outils génériques pour effectuer et valider ces opérations depuis ggsci:

dblogin userid gg, password gg
Successfully logged into database.

add trandata scott.dept
Logging of supplemental redo data enabled for table SCOTT.DEPT.

info trandata scott.dept
Logging of supplemental redo log data is enabled for table SCOTT.DEPT

Fichiers paramètres

J’ai appelé mon extract scott. Il capture les changements DML réalisés sur la table SCOTT.DEPT et les envoie dans le fichier TRAIL distant, qui dans mon cas particulier est géré sur la même instance que celle de l’extract. J’ai nommé mon réplicat demo. Les fichiers de paramètres des groupes scott et demo doivent ressembler à ceux ci-dessous :

help edit params

edit params scott

view params scott

extract scott
userid gg, password gg
rmthost localhost mgrport 7809
rmttrail SC
table SCOTT.DEPT;

edit params demo

view params demo

replicat demo
assumetargetdefs
userid gg, password gg
map SCOTT.DEPT, target DEMO.DEPT;

Note:
Avec la base de données Oracle, il faut utiliser des guillemets pour gérer des noms de table avec des minuscules. Toutefois, ce n’est pas le cas de tous les moteurs de bases de données et GoldenGate est donc très sensible à la casse de votre paramétrage. Pour éviter les problèmes j’utilise des valeurs de paramètres en majuscule à moins que je veuille spécifiquement que ceux-ci soient en minuscule.

Extract et Replicat

Une fois les fichiers de paramètres définis, ajoutez les extract, replicat et trail depuis ggsci:

add extract scott, tranlog, begin now
EXTRACT added.

add rmttrail SC, extract scott
RMTTRAIL added.

add replicat demo, exttrail SC, nodbcheckpoint, begin now
REPLICAT added.

Et démarrer la configuration:

start er *
Sending START request to MANAGER ...
EXTRACT SCOTT starting

Sending START request to MANAGER ...
REPLICAT DEMO starting

info all

Program     Status      Group       Lag           Time Since Chkpt
MANAGER     RUNNING
EXTRACT     RUNNING     SCOTT       00:00:00      00:00:02
REPLICAT    RUNNING     DEMO        00:00:00      00:00:08

view ggsevt

exit

Mes changements sont-ils répliqués ?

Une fois la configuration réalisée, vous pouvez tester la réplication avec les ordres SQL ci-dessous :

sqlplus / as sysdba

update scott.dept
   set dname='OPERATIONS2'
 where deptno=40;

commit;

select dname from demo.dept
  where deptno=40;

DNAME
--------------
OPERATIONS2

update scott.dept
   set dname='OPERATIONS'
 where deptno=40;

commit;

select dname from demo.dept
  where deptno=40;

DNAME
--------------
OPERATIONS

exit

Supprimer votre configuration

Evidemment, il s’agit simplement d’un début et vous irez bientôt beaucoup plus loin. Pour éviter toute erreur dans vos prochains tests, supprimer la configuration une fois que vous en avez fait le tour :

./ggsci

stop er *
Sending STOP request to EXTRACT SCOTT ...
Request processed.

Sending STOP request to REPLICAT DEMO ...
Request processed.

delete er *
Are you sure you want to delete all groups? y
Deleted EXTRACT SCOTT.
Deleted REPLICAT DEMO.

stop manager
Manager process is required by other GGS processes.
Are you sure you want to stop it (y/n)? y

Sending STOP request to MANAGER ...
Request processed.
Manager stopped.

exit

Ensuite, je supprime les utilisateurs demo et gg :

sqlplus / as sysdba

drop user gg cascade;
drop user demo cascade;

exit