Après avoir configuré notre premier flux de réplication entre notre base 11G et 19C, que celui est opérationnel et que vous n’avez noté aucun problème d’intégrité sur votre base cible 19C, il est maintenant temps que vos applications profitent de la belle 19C.
Pour ce faire, il y aura 2 étapes importantes :
- La création d’un second flux de réplication à l’identique du premier mais en sens inverse que nous activerons au moment souhaité (attention, vous ne pouvez pas réutiliser vos Endpoint Connections déjà configurés)
- Procéder à la bascule à proprement parlé dont nous parlerons ci-après
Connexion des applications à la 19C et bascule du flux de réplication 19C -> 11G
L’utilisation de cette méthode vous permettra en cas de rollback (retour des applications sur la 11G) d’avoir un temps d’indisponibilité le plus réduit possible.
- Vérifier s’il y a des désynchronisations importantes entre les tables des 2 bases
- Lister les objets invalides sur la 11G et la 19C afin d’avoir un état des lieux
- Création d’un DBLINK sur la 11Get la 19C que nous utiliserons dans notre import
- Locker les comptes applicatifs sur la base 11G
- Stopper les applications sur la base 11G
- Contrôler qu’aucune connexion applicative n’est présente sur la base 11G
- Déconnecter les sessions sur la base 11G
- Stopper la tâche de réplication 11G -> 19C après avoir vérifié qu’il n’y a plus aucune transaction à répliquer lag 0 (sous l’outil Attunity Replicate dans l’onglet Monitor)
- Suppression sur la base 19C des séquences, procédures, fonctions, package (objets non répliqués) afin de repartir au même niveau que la source
- Import par dblink des séquences, procédures, fonctions, package sur la base 19C
- Activation des triggers sur la nouvelle source 19C
- Activer toutes les foreign key désactivées sur la nouvelle source 19C
- Désactivation des triggers sur la nouvelle cible 11G
- Désactiver toutes les foreign key activées sur la nouvelle cible 11G
- Exécuter un rafraîchissement manuel des vues matérialisées sur la nouvelle source 19C
- Effectuer un spool dans un fichier plat des vues matérialisées ayant un refresh on commit et passer les vues matérialisées de refresh on COMMIT à refresh on DEMAND sur la nouvelle cible 11G
- Désactiver tout traitement qui mettrait les données à jour sur la nouvelle cible 11G après les avoir reçus de la nouvelle source 19C
- Lister les objets invalides sur la nouvelle source 19C et les recompiler si nécessaire
- Récupérer le SCN de la nouvelle source 19C
- Plugger les applications sur la base 19C (modification des entrées du tnsnames.ora)
- Unlock des comptes applicatifs sur la nouvelle source 19C
- Démarrer la tâche de réplication 19C -> 11G en mentionnant le SCN récupéré sur la nouvelle source 19C (sous l’outil attunity replicate)
- Replanifier le refresh des vues matérialisées sur la nouvelle source
- Vérifier s’il y a des désynchronisations importantes entre les tables
- Vérifier le fonctionnement du nouveau flux de réplication
Retour arrière
Nos applications rencontrent malheureusement un problème sur Oracle 19C (performance, bug), nous ne trouvons pas la cause rapidement, cela a un impact négatif sur le business, notre flux de réplication 19C->11G est fonctionnel, nous sommes persuadés que le problème ne sera pas présent sur la 11G et bien retournons sous celle-ci. Le but de la méthode ci-dessous est de ne pas perdre de données, de connecter les applications rapidement à la base 11G et d’abandonner nos flux de réplication.
- Locker les comptes applicatifs sur la base 19C
- Stopper les applications sur la base 19C
- Contrôler qu’aucune connexion applicative n’est présente sur la base 19C
- Déconnecter les sessions sur la base 19C
- Stopper la tâche de réplication 19C -> 11G après avoir vérifié qu’il n’y a plus aucune transaction à répliquer lag 0 (sous l’outil Attunity Replicate dans l’onglet Monitor)
- Suppression sur la base 11G des séquences, procédures, fonctions, package (objets non répliqués) afin de repartir au même niveau que la source
- Import par dblink des séquences, procédures, fonctions, package sur la base 11G
- Activation des triggers sur la nouvelle source 11G
- Activer toutes les foreign key désactivées sur la nouvelle source 11G
- Exécuter un rafraîchissement manuel des vues matérialisées sur la nouvelle source 11G
- Plugger les applications sur la base 11G (modification des entrées du tnsnames.ora)
- Unlock des comptes applicatifs sur la nouvelle source 11G
- Replanifier le refresh des vues matérialisées sur la nouvelle source 11G
J’espère que cette série d’articles sur une migration Oracle 11G vers 19C avec l’outil Attunity Replicate vous aura plu. N’hésitez pas à poser vos questions.
SETRA Conseil se rendra disponible pour vous accompagner dans tous vos projets de migration, peu importe la difficulté.
