Ma dernière aventure concerne une migration vers Exadata d’un système décisionnel  hébergé à l’origine sur un système AIX. Une architecture des données tout ce qu’il y a de plus classique avec une base datawarehouse (7 To) et une base datamart (4 To) qui représentent toutes les deux un volume global de 6 To de données sans les indexes.

Le challenge de cette migration était de limiter l’indisponibilité du système décisionnel à son strict minimum et de basculer d’un système à l’autre en un temps record, défi qui au premier abord semble impossible vu les volumes que l’on devait migrer.  En optimisant au maximum la migration des données avec Datapump d’Oracle (ce qui pourrait faire l’objet d’un prochain article), nous annoncions fièrement que nous pouvions reconstruire les bases de données sur Exadata en environ 26 heures ce qui nécessitait forcément une indisponibilité totale du système décisionnel équivalente à la durée de migration des données plus le temps nécessaire à la reconfiguration des applications pour la bascule sur le nouveau système. Malheureusement cette demande était irrecevable pour le client, la seule fenêtre d’indisponibilité envisageable se limitait au grand maximum à 8 heures, cela devenait de plus en plus compliqué voire impossible.

La seule cartouche qui nous restait était de faire notre migration tranquillement à partir des bases Standby  dont on avait au préalable pris le soin d’arrêter le recouvrement des archives pour disposer d’une image statique des données,  puis ensuite il suffisait d’appliquer à partir de notre point de synchronisation pris sur la standby, les mises à jour effectuées sur la source durant la période de migration pour  retrouver nos données à la cible totalement synchronisées. Simple sur le papier puisqu’en définitive on ne réduisait le temps d’indisponibilité pratiquement qu’à l’opération de bascule des applications vers l’Exadata mais la pratique fût toute autre….  Alors vers quel produit se tourner si ce n’est vers GoldenGate dont Oracle nous avait vanté les mérites et qui avançait  être capable de rattraper 24 heures de décalage en 6 heures, je veux bien le croire mais sous certaines conditions dont on était loin de connaître les limites du produit avant de démarrer cette migration.

Déjà nous avions des contraintes au niveau GoldenGate, comme il s’agissait de bases utilisant la compression standard d’Oracle pour réduire un tant soi peu la volumétrie il devient alors impératif d’utiliser le mode ‘integrated extract‘ de GoldenGate, c’est le seul mode qui traite la compression standard des données (CREATE TABLE … COMPRESS).  Mais attention et oui il y a un mais, ces données ne seront pas compressées sur la cible puisque GoldenGate traite les requêtes ensemblistes par des commandes ligne à ligne et donc vous perdrez du coup tout l’intérêt de la compression de vos données qui s’effectue normalement au niveau de la page sur la base cible à moins que vous ne disposiez bien sûr de l’option ‘advanced compression’ mais avec son coût supplémentaire associé. De plus le mode ‘integrated extract’ nécessite obligatoirement que la version de la base source soit 11.2.0.3.0 (ouf ça tombait bien) mais en plus un petit patch doit être appliqué sur la base source pour avoir la garantie que tout fonctionne correctement. (Voir la note MOS 11.2.0.3 Database specific bundle patch for Integrated Extract 11.2.x (Doc ID 1411356.1)

Sûrs de notre coup, nous partons confiants trop peut-être, j’appelle notre expert GoldenGate et comprends très vite qu’il ne connaît pas ce mode spécifique ‘integrated extract’, c’est une nouveauté en effet la version est encore fraîche GG 11.2.1.0.12 en plus il a fallu appliqué un patch du fait de certaines lenteurs du processus d’extraction pour être en version finale 11.2.1.0.14.

Alors quelles sont les quelques règles à respecter pour améliorer les performances et pour que la synchronisation GolgenGate puisse aboutir dans le cas où vous seriez dans un modèle de type décisionnel.

1. Pour les tables volumineuses sans indexes uniques ou clés primaires ce qui est généralement  le cas dans un datawarahouse qui entrepose des données brutes, il est vivement recommandé d’analyser quelles sont les mises à jour qui sont faites sur ces objets (DELETE UPDATE), dans le cas où ces données sont supprimées ou mises à jour de façon ensembliste alors il faudra certainement créer un processus d’application (REPLICAT) spécifique pour chacune des tables concernées ou carrément exclure ces tables du processus de synchronisation car une forte dégradation des performances est à prévoir du fait que GoldenGate traite ligne à ligne la transaction ensembliste. Ainsi chaque ligne traitée entraîne une lecture complète de la table par GoldenGate qui identifie la ligne à modifier avec la totalité des colonnes qui compose la table. En cas d’exclusion il faudra simplement récupérer la ou les tables par un CAS (Create As Select) via un lien réseau sur la base source (DB_LINK). L’autre solution possible est de créer un index sur ces objets sur la base cible en ayant pris soin auparavant de déterminer quelles sont les colonnes qui constituent ce critère d’unicité mais tout cela doit être anticipé.
2. Les tables temporaires (GLOBAL TEMPORARY) sont traitées comme des tables standards aussi il faut absolument les exclure du processus de GoldenGate (MAPEXCLUDE  EASYTEAM.ZZ*)
3. Dans le cas où des objets sont créés à partir d’objets distants (CAS via DB_LINK) il n’y a aucune garantie que les données soient cohérentes car entre le moment où la transaction est faite sur la base source et celui où la même transaction est appliquée sur la base cible par GoldenGate un certain laps de temps peut s’écouler et qui ne garantit aucunement que les données distantes soient toujours identiques. Alors la plus grande précaution doit être prise pour identifier quels sont les objets qui pourraient être mis à jour par des données distantes. De toute façon pour les liens privés, GoldenGate se verra refuser l’utilisation de ces liens la seule solution envisageable sera de transformer ces liens ‘réseau’ privés en liens publics.
4. Pour de meilleures performances il faudra aussi désactiver toutes les clés étrangères (DISABLE) et permettre la parallélisation des réplications au niveau des tables sur la base cible.
5. Pour la cohérence des données il faudra désactiver tous les jobs Oracle ainsi que les ‘triggers’ sur la base cible.
6. Parallélisation des processus de réplication (REPLICAT) par schéma voire par objet pour les tables les plus impactées par les mises à jour Oracle.
7. Bannir la réplication des séquences dans le processus d’extraction GoldenGate qui peut ralentir la synchronisation.

Alors si d’aventure vous vous embarquiez dans ce type de migration, prenez toutes les précautions et garanties pour mener à bien votre projet. Une pré-étude doit être envisagée pour bien délimiter le périmètre des objets ne répondant pas aux critères d’unicité de GoldenGate. Si vous avez besoin de conseils dans cette phase préparatoire n’hésitez pas à nous contacter nous vous éviterons bien des pièges.

Je tiens à préciser que cet article résulte d’une expérience vécue sur le terrain, de plus je tiens tout particulièrement à remercier Pierre pour son soutien et son sens inné de l’anticipation pour éviter les écueils ….