Tout le monde connait Oracle dataguard pour sa gestion de la haute disponibilité, notamment lorsque l’on souhaite mettre en place un plan de secours (PRA ou PSI) pour son système d’informations.
Dataguard nécessite une version EE (Enterprise Edition) pour être implémenté, mais présente l’énorme avantage d’être facile à configurer et à utiliser, en particulier si vous utilisez le Dataguard Broker (dgmgrl) comme je vais vous le démontrer dans cet article.
La mise en œuvre de dataguard, par rapport au coût qu’il engendre (doublement des capacités CPU, mémoire et disques), peut parfois sembler exorbitant en regard du peu de fois où cette solution est utilisée.
C’est pourquoi je vais parler dans cet article d’une possibilité de rentabiliser votre dispositif Dataguard en vous permettant :

• de mettre rapidement à disposition un environnement prod-like
• de reproduire un bug applicatif sur des données récentes de production
• de jouer des tests de non régression par rapport à une montée de version applicative
• de simuler une bascule dataguard pour tester un PRA

Cette possibilité est apparue en version Oracle 11gR2 et se nomme : snapshot standby database.
Le principe est simple, et consiste en l’isolement provisoire de la base secondaire (physical standby), et conversion de cette base secondaire pour pouvoir l’ouvrir en lecture-écriture.
Une fois l’utilisation de cette base secondaire en tant que snapshot standby  terminée, il vous suffira de la convertir dans son mode d’origine (physical standby) pour qu’elle reprenne naturellement sa place dans le dispositif Dataguard en reprenant sa réplication juste au moment ou l’aviez stoppée.
Maintenant, voyons ensemble les quelques commandes à connaitre et à passer pour réaliser cet exercice :
1.  Il faut tout d’abord s’assurer que la synchronisation entre la base primaire (PRIMARY) et la base de secours (PHYSICAL STANDBY) est parfaite
dgmgrl
Welcome to DGMGRL, type "help" for information.
connect sys/<password>
Connected.
DGMGRL> show configuration ;
Configuration - dgbase
Protection Mode: MaxPerformance
Databases:
base1 - Primary database
base2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
2.  Il faut ensuite configurer la base de secours en mode FLASHBACK, en configurant, si ce n’est pas déjà le cas, une FRA (Fast Recovery Area)
Configurer dans l’ordre suivant les paramètres dynamiques d’instance :
db_recovery_file_dest_size = 100G (Attention, cette taille doit vous permettre de tenir pendant toute la durée de vos tests)
db_recovery_file_dest = <filesystem où seront stockés les flashback logs>
db_flashback_retention_target = 1440 (par défaut, soit 1 journée de 24 heures)
Activer le mode FLASHBACK sur la base de secours :
sqlplus / as sysdba
SQL> alter database recover managed standby database cancel ;           # pour stopper la réplication.
Database altered.
SQL> alter database flashback on ;                                                            # pour activer le FLASHBACK DATABASE
Database altered.
SQL> select flashback_on from v$database ;                                            # vérifier l'activation du FLASHBACK
FLASHBACK_ON
------------------------------------------------------
YES
SQL> alter database recover managed standby database disconnect ;    # pour reprendre la réplication
Database altered.
3. Convertir votre base de secours (PHYSICAL STANDBY) en SNAPSHOT STANDBY
dgmgrl
connect sys/<password>
Connected.
DGMGRL> convert database base2 to snapshot standby ;
Converting database "base2" to a Snapshot Standby database, please wait...
Database "base2" converted successfully
DGMGRL>
DGMGRL> show configuration ;
Configuration - dgbase
Protection Mode: MaxPerformance
Databases:
base1 - Primary database
base2 - Snapshot standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
Votre base de secours est maintenant ouverte aux utilisateurs et peut commencer à enregistrer les modifications apportées dans les flashback logs, ce qui permettra en fin d’utilisation de cette base de secours, d’effectuer un retour arrière sur ces modifications, puis de reprendre la réplication juste avant l’interruption de cette dernière.
4. Surveiller le taux d’occupation de la FRA

Au besoin, augmenter le dimensionnement de la FRA (alter system set db_recovery_file_dest_size = 100g).
5. Lorsque les tests sur la base de secours sont terminés, remettre en œuvre la réplication
dgmgrl
connect sys/<password>
Connected.
DGMGRL> convert database base2 to physical standby ;
Converting database "base2" to a Physical Standby database, please wait...
Operation requires shutdown of instance "base2" on database "base2"
Shutting down instance "base2"...
Database closed.
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "base2" on database "base2"
Starting instance "base2"...
ORACLE instance started.
Database mounted.
Continuing to convert database "base2" ...
Operation requires shutdown of instance "lifedbc" on database "base2"
Shutting down instance "base2"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "base2" on database "base2"
Starting instance "base2"...
ORACLE instance started.
Database mounted.
Database "base2" converted successfully
DGMGRL> show configuration ;
Configuration - dgbase
Protection Mode: MaxPerformance
Databases:
base1 - Primary database
base2 - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS
C’est terminé, la réplication est repartie à l’endroit même ou vous l’aviez interrompue.
Remarque importante :
L’opération de FLASHBACK sur la base, lors du CONVERT TO PHYSICAL STANDBY change son incarnation.
Par conséquent, si vous utilisez la SNAPSHOT STANDBY database, et que dans la vie de votre base, vous devez un jour réinitialiser la base de secours (ex: corruption de la base standby, ou perte de synchro depuis plusieurs jours ou semaines), il faudra vous souvenir de la commande RMAN : RESET DATABASE TO INCARNATION xx ; pour la remettre au niveau de la dernière incarnation de la base primaire.