Oracle Database 11.2 (aka 11gR2) offre un nouveau paramètre de session nommé standby_max_data_delay. Ce paramètre permet d’assurer que vos requêtes, sur une base de données physical standby, lorsquelle est en mode real-time query, retournent des données suffisamment récentes. Cette contrainte, que vous positionnez en secondes, peut aller jusqu’à préciser que les données retournées par votre requête sont consistentes avec les données sur votre base de données primaire au moment de l’exécution de la requête, quand vous précisez standby_max_data_delay=0. Dans cet article, vous trouverez quelques exemples d’utilisation de ce paramètre et quelques limites associées.

Cet article est le quatrième de la série que je vous invite à découvrir ci-dessous :

• Le 1er article, présente comment créer une configuration Data Guard en 5 minutes, en plus du temps de copie de la base de données et comment effectuer une transition des roles des bases de données
• Le 2nd article, présente comment changer le mode de protection, activer la compression, Snapshot Standby et Real Time Query
• Le 3ème article illustre le fonctionnement de la correction automatique de blocs corrumpus sur la base de données primaire et standby
• Le 4ème article (celui-ci) démontre comment garantir la fraicheur des données sur la standby
• Le 5ème article illustre l’utilisation du Block Change Tracking File sur la base standby et l’utilisation de la commande recover database noredo pour gérer la perte d’un fichier archivelog

Utiliser le paramètre

Dans l’exemple ci-dessous, vous interrogerez la table SCOTT.EMP sur la base de données WHITE en mode standby real-time query. Dans ce cas, vous pourrez constater que la requête fonctionne parfaitement; en fait, si vous poussez un peu plus vos tests, vous constaterez avec une charge limitée et une valeur de 0 pour le paramètre, que l’impact sur le temps d’exécution des requêtes est quasiment nul :

sqlplus scott/tiger@white
alter session set STANDBY_MAX_DATA_DELAY=10;
Session altered
select empno, ename, job
 from emp;
EMPNO ENAME      JOB
----- ---------- ---------
7369  SMITH      CLERK
7499  ALLEN      SALESMAN
7521  WARD       SALESMAN
7566  JONES      MANAGER
7654  MARTIN     SALESMAN
7698  BLAKE      MANAGER
7782  CLARK      MANAGER
7788  SCOTT      ANALYST
7839  KING       PRESIDENT
7844  TURNER     SALESMAN
7876  ADAMS      CLERK
7900  JAMES      CLERK
7902  FORD       ANALYST
7934  MILLER     CLERK
exit

Si en revanche vous arrêtez l’application des fichiers de redo log sur la standby, la requête ne peut plus être exécutée puisque la fraîcheur des données n’est plus garantie:

dgmgrl /
edit database white set state=APPLY-OFF;
Succeeded.
show database white;
Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-OFF
  Transport Lag:   0 seconds
  Apply Lag:       49 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE
Database Status:
SUCCESS
exit
sqlplus scott/tiger@white
alter session set STANDBY_MAX_DATA_DELAY=10;
Session altered
select * from emp;
select * from emp
*
ERROR at line 1:
ORA-03172: STANDBY_MAX_DATA_DELAY of 10 seconds exceeded
exit;

Quelques limites

Si vous êtes interessé par les limites du paramètre, sachez qu’il nécessite, d’après la documentation, que le service de transport des redo log soit configuré en mode synchrone, que le mode de protection soit maximum availability ou maximum protection et que le service de redo apply soit actif. Cependant, ce ne sont pas toute les restrictions comme vous pourrez vous en rendre compte:

• Il faudra que vous soyez connecté avec un autre utilisateur que SYS

SQL> alter session set STANDBY_MAX_DATA_DELAY=10;
ERROR:
ORA-03174: STANDBY_MAX_DATA_DELAY does not apply to SYS users

• Il faudra également que votre base de données soit une standby physique ouverte en mode real time query; si vous changez le paramètre sur une standby logique, vous obtiendrez le message ci-dessous :

SQL> alter session set STANDBY_MAX_DATA_DELAY=10;
ERROR:
ORA-03176: ALTER SESSION SET STANBY_MAX_DATA_DELAY only works on an open
physical standby database

Conclusion

Voilà qui conclut ce quatrième volet dédié à Oracle Database 11g Release 2 Data Guard. Si vous aimez cette série, sachez qu’il y aura finalement une sixième sequelle, en attendant une bonne idée, peut-être, pour une septième; que pensez-vous qu’il faille y ajouter ?