Dataguard : Snapshot Standby

Lorsque l’on souhaite disposer d’une base de données standby permettant l’accès en consultation, Oracle propose la fonctionnalité Active Dataguard. Cette dernière consiste en le fait d’ouvrir une base de données standby, qui sera implicitement ouverte en mode « READ ONLY WITH APPLY ».

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE    OPEN_MODE
---------------- --------------------
PHYSICAL STANDBY READ ONLY WITH APPLY

Cette fonctionnalité est très puissante car elle permet simultanément l’application des redo en provenance de la base primaire, et la consultation des données ainsi rafraichies en temps réel. Son gros défaut cependant est son coût, puisque l’option est soumise à licence. Il existe cependant une solution similaire qui utilise une technologie faisant partie de l’édition Enterprise, la fonctionnalité de SNAPSHOT STANDBY.

Cette fonctionnalité permet de convertir à la demande une base de données PHYSICAL STANDBY en SNAPSHOT STANDBY. Lors de cette conversion, un snapshot de la base de données est pris. A partir de ce moment là, la standby sera ouverte en mode READ-WRITE, et ce jusqu’à la conversion inverse en PHYSICAL STANDBY, qui déclenchera la restauration du snapshot, ainsi que la reprise de l’application des redo logs en provenance de la primaire.

On peut alors par exemple définir deux phases dans une journée : la nuit la base standby est en mode nominal (physical standby). Le matin un script planifié va convertir la base de données en snapshot database, elle sera alors ouverte en READ-WRITE. La journée la base est consultable et modifiable, ce qui permet d’accommoder des tests sur des données iso-production, en plus de la simple possibilité de consultation de l’Active Dataguard.

Mise en place

Nous allons voir comment mettre en place cette fonctionnalité sur une installation Dataguard basique en version 12.1.0.2.

La base de données standby au status MOUNT. La configuration du Dataguard broker est déjà en place :

DGMGRL> show configuration;

Configuration - omega_dg

  Protection Mode: MaxPerformance
  Members:
  OMEGA_PRI - Primary database
    OMEGA_STD - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS   (status updated 38 seconds ago)

DGMGRL> show database 'OMEGA_STD';

Database - OMEGA_STD

  Role:               PHYSICAL STANDBY
  Intended State:     APPLY-ON
  Transport Lag:      0 seconds (computed 1 second ago)
  Apply Lag:          0 seconds (computed 1 second ago)
  Average Apply Rate: 1.00 KByte/s
  Real Time Query:    ON
  Instance(s):
    OMEGA

Database Status:
SUCCESS

Depuis la primaire, se connecter au broker avec authentification par fichier de mot de passe, l’authentification OS étant à proscrire pour certaines fonctions du broker :

dgmgrl SYS/@OMEGA_PRI_DGMGRL

Convertir la base physical standby en snapshot standby via la commande suivante :

DGMGRL> CONVERT DATABASE 'OMEGA_STD' TO SNAPSHOT STANDBY;
Converting database "OMEGA_STD" to a Snapshot Standby database, please wait...
Database "OMEGA_STD" converted successfully

A partir de ce moment, la base de données standby est ouverte en lecture/écriture avec le rôle de SNAPSHOT DATABASE :

SQL> select database_role,open_mode from v$database;

DATABASE_ROLE    OPEN_MODE
---------------- --------------------
SNAPSHOT STANDBY READ WRITE

On pourra alors à notre convenance créer, modifier utilisateurs et objets, modifier des données etc. afin d’accommoder des cas de test.

create user test_user identified by secret;
grant resource,connect to test_user;
grant unlimited tablespace to test_user;
connect test_user;

SQL> create user test_user identified by secret;

User created.

SQL> grant resource,connect to test_user;

Grant succeeded.

SQL> grant unlimited tablespace to test_user;

Grant succeeded.

SQL> connect test_user;
Enter password:
Connected.

SQL> create table test_snap_db (id number);

Table created.

create table test_snap_db (id number);
SQL> insert into test_snap_db values (1);

1 row created.

SQL> insert into test_snap_db values (2);

1 row created.

SQL> insert into test_snap_db values (3);

1 row created.

Une fois les tests réalisés sur la base de données SNAPSHOT, on peut la reconvertir en son état initial PHYSICAL STANDBY via le Dataguard broker :

dgmgrl SYS/@OMEGA_PRI_DGMGRL
DGMGRL> CONVERT DATABASE 'OMEGA_STD' TO PHYSICAL STANDBY;
Converting database "OMEGA_STD" to a Physical Standby database, please wait...
Oracle Clusterware is restarting database "OMEGA_STD" ...
Continuing to convert database "OMEGA_STD" ...
Database "OMEGA_STD" converted successfully

La base de données est désormais reconvertie en PHYSICAL STANDBY, et de ce fait resynchronisée avec la primaire. Un coup d’œil à la base standby nous montre que l’utilisateur de test créé précédemment n’existe plus.

SQL> select count(*) from dba_users where username = 'TEST_USER';

  COUNT(*)
----------
         0

On voit donc l’intérêt de cette fonctionnalité. On peut imaginer une conversion chaque matin en SNAPSHOT STANDBY, avec retour en PHYSICAL STANDBY le soir. Ce genre de planification permettrait de faire des tests unitaires en journée qui sont effacés chaque soir, et remplacer le classique rafraichissement via DUPLICATE ou restore de backup. On peut aussi imaginer garder la standby en mode SNAPSHOT pour plusieurs jours pour réaliser des tests plus poussés sur la durée.