Oracle 11g Release 2 Data Guard (3/5) : Automatic Block Media Recovery

Le “Block Media Recovery” ou BMR est la possibilité de restaurer un bloc Oracle en cas de corruption. Jusqu’à Oracle 11g Database Release 1, seul Oracle Oracle Recovery Manager, RMAN, permet de restaurer simplement un bloc. Avec la version 11.2 de la base de données, lorsque vous utilisez Active Data Guard et que vous utilisez une standby database et Real Time Query, les corruptions de données sont corrigées automatiquement. Cette nouvelle fonctionnalité permet d’éviter les erreurs ORA-01578 de manière automatique et quasiment transparente. Cette article illustre cette fonctionnalité à travers une méthode simple pour corrompre, tour à tour, la base de données primaire et la standby.

Cet article est le troisième d’une série plus large 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 (celui-ci) illustre le fonctionnement de la correction automatique de blocs corrumpus sur la base de données primaire et standby
• Le 4ème article 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

Il s’agit d’un tour d’horizon assez complet de l’état de l’art de Data Guard en 11g Release 2. Bien sur, si vous avez d’autres idées, n’hésitez pas à les partager en laissant vos commentaires…

Préambule

Pour commencer, il faut configurer une standby physique en “real time query”. Pour cela, je vous renvoie au premier article et au second article de la série. Dans la configuration qui suit, BLACK est la base de données primaire et WHITE, la base de données standby en real time apply. J’ai effectué mes tests sur Linux x86.

dgmgrl sys/change_on_install@black

show database white;

Database - white
  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: ON
  Instance(s):
    WHITE

Database Status:
SUCCESS

exit

Corruption d’un bloc sans une Standby “Real Time Query”

Pour commencer, vous pouvez désactiver la base de données standby “Real Time Query” pour visualiser ce qu’il se passe lorsque un bloc est corrompu sans Active Data Guard. Pour cela, connectez-vous à la standby avec le client du broker et démarrer la base standby en mode mount :

dgmgrl sys/change_on_install@white

shutdown abort
ORACLE instance shut down.
startup mount;
ORACLE instance started.
Database mounted.
show database white;

Database - white

Role:            PHYSICAL STANDBY
Intended State:  APPLY-ON
Transport Lag:   0 seconds
Apply Lag:       0 seconds
Real Time Query: OFF
Instance(s):
WHITE

Database Status:
SUCCESS

exit;

Pour la suite, nous allons répérer un bloc à corrompre. Pour cet exemple, nous allons utiliser la table exemple SCOTT.EMP. Le package DBMS_ROWID permet de repérer le bloc d’une ligne à partir de son rowid :

sqlplus sys/change_on_install@black as sysdba

set serveroutput on

declare
   v_rowid_type number;
   v_object_number number;
   v_relative_fno number;
   v_block_number number;
   v_row_number number;
begin
   for i in (select rowid, ename
            from scott.emp) loop
      dbms_rowid.ROWID_INFO(
            i.rowid,
            v_rowid_type,
            v_object_number,
            v_relative_fno,
            v_block_number,
            v_row_number);
      dbms_output.put_line(
            'Employee: '||i.ename||
            ' - block: '||to_char(v_block_number ));
   end loop;
end;
/

Employee: SMITH - block: 151
Employee: ALLEN - block: 151
Employee: WARD - block: 151
Employee: JONES - block: 151
Employee: MARTIN - block: 151
Employee: BLAKE - block: 151
Employee: CLARK - block: 151
Employee: SCOTT - block: 151
Employee: KING - block: 151
Employee: TURNER - block: 151
Employee: ADAMS - block: 151
Employee: JAMES - block: 151
Employee: FORD - block: 151
Employee: MILLER - block: 151

Nous allons donc corrompre le bloc 151 de notre datafile. Pour cela, nous allons utiliser la commande dd qui est facile à utiliser lorsque vous n’utilisez pas Automatic Storage Manager (Avec ASM, il faut d’abord repérer la position des extents du datafiles dans le diskgroup). Après que vous ayez corrompu le bloc, Oracle vous retourne l’erreur ORA-01578 lorsque vous tentez d’y accéder :

select file_name
   from dba_data_files
 where tablespace_name='USERS';

FILE_NAME
-----------------------------------------
/u01/app/oracle/oradata/BLACK/users01.dbf

! ls -l /u01/app/oracle/oradata/BLACK/users01.dbf

! dd if=/dev/zero -
   of=/u01/app/oracle/oradata/BLACK/users01.dbf -
   bs=8k count=1 seek=151 conv=notrunc

alter system flush buffer_cache;

select * from scott.emp;
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 4, block # 151)
ORA-01110: data file 4: '/u01/app/oracle/oradata/BLACK/users01.dbf'

exit;

Note
le paramètre conv=notrunc de la commande dd permet de ne pas tronquer le fichier après le bloc que vous modifiez, ce qui est le comportement par défaut.

Corriger un bloc corrompu avec la base de données Standby “Real Time Query”

Pour corriger le bloc corrompu, vous pouvez bien entendu utiliser Recovery Manager; Au lieu de celà, nous allons simplement activer la standby en mode “Real Time Query” :

dgmgrl sys/manager@white

show database white;

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: OFF
  Instance(s):
    WHITE

Database Status:
SUCCESS

shutdown immediate;
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.

startup
ORACLE instance started.
Database mounted.
Database opened.

show database white;

Database - white

  Role:            PHYSICAL STANDBY
  Intended State:  APPLY-ON
  Transport Lag:   0 seconds
  Apply Lag:       0 seconds
  Real Time Query: ON
  Instance(s):
    WHITE

Database Status:
SUCCESS

exit;

Maintenant, il suffit d’accéder au bloc corrompu sur la base de données primaire pour corriger l’erreur :

sqlplus sys/change_on_install@black as sysdba

set pages 1000

select empno, ename
  from scott.emp;

EMPNO ENAME
----- -------
 7369 SMITH
 7499 ALLEN
 7521 WARD
 7566 JONES
 7654 MARTIN
 7698 BLAKE
 7782 CLARK
 7788 SCOTT
 7839 KING
 7844 TURNER
 7876 ADAMS
 7900 JAMES
 7902 FORD
 7934 MILLER

L’erreur est corrigée, comme par magie. Pour comprendre ce qui s’est passé, allez voir le fichier alert.log et vous y découvrirez un message indiquant que la correction automatique du bloc a été déclenchée. Voici le-dit extrait sur ma base de données :

Sun Oct 04 13:27:13 2009
Hex dump of (file 4, block 151) in trace file /u01/app/oracle/diag/rdbms/black/BLACK/trace/BLACK_ora_15682.trc
Corrupt block relative dba: 0x01000097 (file 4, block 151)
Completely zero block found during buffer read
Reading datafile '/u01/app/oracle/oradata/BLACK/users01.dbf' for corruption at rdba: 0x01000097 (file 4, block 151)
Reread (file 4, block 151) found same corrupt data
Starting background process ABMR
Sun Oct 04 13:27:13 2009
ABMR started with pid=37, OS id=15692
Auto BMR service is active.
Requesting Auto BMR for (file# 4, block# 151)
Waiting Auto BMR response for (file# 4, block# 151)
Auto BMR successful

Quel est l’impact de la correction automatique de la corruption ?

Re-faîtes le même test, cette fois-ci en ayant déjà la base de données en mode “Real Time Query”

• Sans corruption de données

sqlplus / as sysdba

alter system flush buffer_cache;

set timing on
select empno, ename
  from scott.emp;
[...]
Elapsed: 00:00:00.01

• Avec corruption de données

sqlplus / as sysdba

! dd if=/dev/zero -
   of=/u01/app/oracle/oradata/BLACK/users01.dbf -
   bs=8k count=1 seek=151 conv=notrunc

alter system flush buffer_cache;

set timing on
select empno, ename
  from scott.emp;
[...]
Elapsed: 00:00:00.48

Vous pouvez encore vérifier dans le fichier alert.log que la gestion automatique du “Block Media Recovery” a été déclenchée. Vous constaterez que si l’impact n’est pas transparent, il est relativement négligeable; bien sur, ce temps dépend du lag de la standby.

Corruption de la base de données Standby

La gestion automatique de la corruption de bloc est également disponible sur la standby. Pour vous en persuader, vous pouvez effectuer le même test depuis la base standby en mode “Real Time Query”. Remarquez que dans ce cas, voulu(*) ou pas une erreur est renvoyée à l’utilisateur :

sqlplus sys/change_on_install@white as sysdba

alter system flush buffer_cache;

! dd if=/dev/zero -
   of=/u01/app/oracle/oradata/WHITE/users01.dbf -
   bs=8k count=1 seek=151 conv=notrunc

select empno, ename
from scott.emp;
*
ERROR at line 2:
ORA-01578: ORACLE data block corrupted (file # 4, block # 151)
ORA-01110: data file 4: '/u01/app/oracle/oradata/WHITE/users01.dbf'

Si vous ré-exécutez la requête, le bloc est corrigé :

select empno, ename
   from scott.emp;

EMPNO ENAME
----- --------
 7369 SMITH
 7499 ALLEN
 7521 WARD
 7566 JONES
 7654 MARTIN
 7698 BLAKE
 7782 CLARK
 7788 SCOTT
 7839 KING
 7844 TURNER
 7876 ADAMS
 7900 JAMES
 7902 FORD
 7934 MILLER

Le fichier alert.log montre que la corruption est détectée :

Hex dump of (file 4, block 151) in trace file /u01/app/oracle/diag/rdbms/white/WHITE/trace/WHITE_ora_17556.trc
Corrupt block relative dba: 0x01000097 (file 4, block 151)
Completely zero block found during multiblock buffer read
Reading datafile '/u01/app/oracle/oradata/WHITE/users01.dbf' for corruption at rdba: 0x01000097 (file 4, block 151)
Reread (file 4, block 151) found same corrupt data
Errors in file /u01/app/oracle/diag/rdbms/white/WHITE/trace/WHITE_ora_17556.trc  (incident=97362):
ORA-01578: ORACLE data block corrupted (file # 4, block # 151)
ORA-01110: data file 4: '/u01/app/oracle/oradata/WHITE/users01.dbf'
Incident details in: /u01/app/oracle/diag/rdbms/white/WHITE/incident/incdir_97362/WHITE_ora_17556_i97362.trc
Sun Oct 04 14:03:07 2009
Sweep [inc][97362]: completed
Sun Oct 04 14:03:08 2009
Trace dumping is performing id=[cdmp_20091004140308]
Sun Oct 04 14:03:09 2009
Sweep [inc2][97362]: completed

Conclusion

Ces changements, à priori mineurs, à la lumière de ces tests, non seulement fonctionnent mais apportent un vrai plus à l’infrastructure Active Data Guard. Et ce n’est qu’un début puisque dans le prochain article, nous testerons la possibilité offerte par la standby “Real Time Query” de garantir la fraicheur des données interrogée sur la base secondaire. J’espère pouvoir vous faire partager notre enthousiasme pour ces nouvelles fonctionnalités. Qu’en pensez-vous ?

(*) La base de données standby a un SCN plus petit, même très proche, que le SCN de la base de données primaire; il est possible que la requête doivent être arrêtée parce que la standby ne peut pas garantir que le bloc remonté ne contient pas des données modifiées depuis. Ceci dépend de la manière dont le bloc est accédé et il se peut que ce soit une limite de l’implémentation actuelle (malgré la présence des UNDO). Il faudrait activer les traces sur la primaire et démonter le mécanisme pour en savoir plus. Y a-t-il un curieux/courageux pour comprendre ce qu’il se passe plus en détail ?