Oracle 11g Release 2 Data Guard (4/5) : Garantir la fraicheur de vos requêtes

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 :

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 ?

9 réflexions sur “Oracle 11g Release 2 Data Guard (4/5) : Garantir la fraicheur de vos requêtes”

  1. Ping : Oracle Database 11g Release 2 Data Guard (7/5): Observer et Fast Start Failover | EASYTEAM

  2. Ping : Active Data Guard 11g Release 2 (5/5) : BCTF et RECOVER NOREDO sur la Standby | EASYTEAM LE BLOG

  3. Ping : Oracle Database 11g Release 2 Data Guard (7/5): Observer et Fast Start Failover « EASYTEAM LE BLOG

  4. Ping : Oracle Database 11g Release 2 Data Guard (6/5): Créer une standby logique avec le broker « EASYTEAM LE BLOG

  5. Andrey Goryunov

    Gregory,
    everything is alright, Spring is coming and Summer is not far away!
    Thanks for your blog posts!
    In regards of 11.2 and silent installation, do you have plans to blog
    about changes there?
    Thanks,
    Andrey

  6. Hi Andrey,
    Nice to hear from you. I wish you’re doing good! How is Spring?
    The new 11gR2 RMAN duplicate with no connection to the target is by far one of my favorite new features. I blogged about it in the beginning of Sept. It’s easy with the ‘to destination’ backup clause. It shrinks scripts by an order of magnitude and nicely address a bunch of issues you have with 11.1 and previous releases like (1) the directory trees are very different between servers or (2) you want to scripts without managing password stores. I’ve also blogged about TSPITR after the TS drop.
    I’ve tested BMR with only a real time query standby in place (check the 3/5 post comments in this data gard serie); I’m not sure that’s actually listed in the NF section or at least what is described sounds a different beast.
    I did not really test the other features that appear to me like more specific changes: convert… skip unnecessary datafiles, compression algorith, all/current incarnation syntax.
    So yes RMAN 11.2 is really great. Too bad I’ve not upgraded all our database yet!
    Gregory

  7. Andrey Goryunov

    Hi Gregory!
    I won’t be using translator for writing as I am using it for reading of your blogs 🙂
    but have you found some interesting changes in RMAN for 11g (1,2)?
    I think there are some things to blog about
    Regards
    Andrey

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *