DATAGUARD ET RAFRAICHISSEMENT DES ENVIRONNEMENTS
(3E PARTIE)

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

V - Les étapes de la deuxième phase
Il s'agit de réintégrer la base de pré-production et de tests dans son rôle de standby database.

Etape 1 : Re-démarrer la database activée avec les options mount et force et procéder à son flashback jusqu'au restore point
SQL> startup mount force
SQL> archive log list ;
SQL> flashback database to restore point bf_app_test ;

Etape 2 : Convertir la database activée en physical standby database et la re-démarrer avec les options mount et force
SQL> alter database convert to physical standby ;
SQL> startup mount force

Etape 3 : Lancer la récupération managée sur la standby
SQL> alter database recover managed standby database disconnect ;

Etape 4 : Activer le transport des logs archivés depuis la primary vers la standby et noter le numéro de séquence courante sur la primary
Sur la primary
SQL> alter database set log_archive_dest_state_2=enable scope=both ;
SQL> select database_role, open_mode from v$database ;
SQL> alter system switch logfile ;
SQL> archive log list ;

Etape 5 : Vérifier que les logs archivés sont bien appliqués sur la standby
SQL> select database_role, open_mode from v$database ;
SQL> archive log list ;

Etape 6 : Vérifier l'application des logs archivés en temps réel dans le fichier d'alertes de la standby database
$ tail –f /u01/app/oracle/product/10.2.0/db_1/dbs/alertstbyprod.log

Dans l'un de nos prochains posts, nous verrons comment Oracle a permis de simplifier davantage cette même procédure dans Oracle Database 11g avec la nouvelle fonctionnalité snapshot standby.

Webographie
Oracle Data Guard Concepts and Administration 10g Release 2 (10.2) – Chapter 12.6 : Using a Physical Standby Database for Read/Write Testing and Reporting

Fin ./.