Sunday, September 06, 2009

DATAGUARD ET RAFRAICHISSEMENT DES ENVIRONNEMENTS
(1ERE PARTIE)

Cet article a été rédigé en collaboration avec M. Akli IMARAZENE, Consultant et DBA.


I - Introduction

Une configuration Dataguard a deux fonctions principales :
- Assurer la protection des données de l'entreprise ;
- Concourir à la haute disponibilité de la base de données de production par la capacité de la base de secours (standby) à participer à une permutation de rôles avec la base de production (primary) lors de maintenances planifiées ou suite à une panne de la base de données de production.
Il y une troisième fonction beaucoup moins connue que l'on peut faire jouer à une configuration Dataguard : celle de servir au rafraîchissement des bases de données de pré-production, de tests et/ou de développement.
Il y a quelques jours, un ami et collègue m'expliquait toutes les difficultés qu'il a eues à faire accepter par ses collègues DBAs et sa hiérarchie la mise en œuvre d'une configuration Dataguard pour assurer le rafraîchissement d'une base de données de tests malgré l'argument incontestable que constitue l'extraordinaire gain en temps que cela allait procurer au quotidien.
La réaction des collègues et de la hiérarchie de mon collègue est d'autant plus surprenante que la maîtrise de la mise en œuvre d'une configuration Dataguard n'est pas une tâche insurmontable et que de toutes les manières la mise en œuvre sera précédée de tests approfondis devant déboucher sur une procédure écrite qui servira de base à un transfert de compétences à tous les DBAs de l'équipe.
Dans cet article, nous nous fixons comme objectif de décrire dans ses grandes lignes une procédure de rafraîchissement d'une base de données de tests à l'aide d'une configuration Dataguard.
Nous supposons que le lecteur maîtrise la mise en place d'une configuration Dataguard car ceci ne sera pas traité dans le présent article.
Nous commencerons par présenter la configuration Dataguard qui servira de base à nos propos ; ensuite nous décrirons les différentes étapes à franchir pour aboutir au résultat escompté.

II - Présentation de la configuration Dataguard
Notre configuration comprend une base de données de production dite primary database et une base de données de tests (la base de données qui a besoin d'être rafraîchie tous les matins) qui va jouer le rôle de base de données secours, dite standby database.
Primary Database
db_name : prod
instance_name : iprod
db_unique_name : uprod

Standby Database
db_name : prod
instance_name : stbyprod
db_unique_name : usprod

III - Principe d'utilisation d'une configuration Dataguard pour le rafraîchissement
Durant toutes les nuits, la standby database joue son rôle de base secours. Il reçoit les archive logs générés sur la primary database et les applique au fil de l'eau.
Tous les matins, le DBA en charge de la gestion de cette configuration exécute les actions suivantes :
- Activer la fonctionnalité flashback database sur la standby database ;
- Arrêter l'application des données de redo sur la standby database ;
- Créer un restore point sur la standby database ;
- Archiver le redo log courant sur la primary database ;
- Différer le transport des redo logs vers la standby database ;
- Transformer la standby database en base de données classique pouvant être utilisée pour des tests avec des opérations de lecture/écriture et enfin l'ouvre et la met à la disposition des équipes de tests.

Tous les soirs, le même DBA lance le rafraîchissement de la base de tests après avoir procédé à un flashback pour annuler toutes les mises à jour faites par les équipes de tests et après l'avoir réintégré dans son rôle de standby database. Les actions menées sont, dans l'ordre :
- Procéder au flashback de la base de données de tests jusqu'au restore point ;
- Convertir la base de données de tests en physical standby database et le mettre en mode récupération manager;
- Activer le transport des logs archivées vers la standby database où ils seront appliqués

A suivre …

Labels: , ,

0 Comments:

Post a Comment

<< Home