Blog

le 04/11/2009
Thomas Bordet
Oracle

Active Data Guard 11g Release 2 (5/5) : BCTF et RECOVER NOREDO sur la Standby

Ce presque dernier article dédié à Oracle Database 11g Release 2 (aka 11gR2) Data Guard, présente 2 sujets qui ont en commun l’utilisation de sauvegardes incrémentales. Il s’agit de l’utilisation du block change tracking file sur la base de données standby et l’utilisation d’un backup incremental pour resynchroniser une standby physique.
Cet article est le cinquiè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 démontre comment garantir la fraicheur des données sur la standby
Le 5ème article (celui-ci) 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

Block Change Tracking File et Standby Database

Pour activer le fichier de block change tracking, il suffit d’utiliser la commande alter database comme ci-dessous :

col status format a8
col filename format a40
set pages 100
select *
  from V$BLOCK_CHANGE_TRACKING;
STATUS	 FILENAME				       BYTES
-------- ---------------------------------------- ----------
DISABLED
col name format a5
col db_unique_name format a14
select name, db_unique_name, open_mode
  from v$database;
NAME  DB_UNIQUE_NAME OPEN_MODE
----- -------------- --------------------
BLACK WHITE          READ ONLY WITH APPLY
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING
    USING FILE '/u01/app/oracle/oradata/WHITE/bctf01.f' reuse;
Database altered.
select *
  from V$BLOCK_CHANGE_TRACKING;
STATUS	 FILENAME				       BYTES
-------- ---------------------------------------- ----------
ENABLED  /u01/app/oracle/oradata/WHITE/bctf01.f     11599872
exit;

Une fois le BCTF activé, vous pouvez effectuer une sauvegarde incrémentale pour initialiser le fichier :

. oraenv
ORACLE_SID = [WHITE] ?
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
rman target /
host 'mkdir -p /u01/app/oracle/backup/WHITE';
configure channel
   device type disk format '/u01/app/oracle/backup/WHITE/%U';
backup incremental level 0 database;
Starting backup at 21-OCT-09
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=146 device type=DISK
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/WHITE/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/WHITE/sysaux01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/WHITE/users01.dbf
input datafile file number=00005
name=/u01/app/oracle/oradata/WHITE/example01.dbf
input datafile file number=00003
name=/u01/app/oracle/oradata/WHITE/undotbs01.dbf
channel ORA_DISK_1: starting piece 1 at 21-OCT-09
channel ORA_DISK_1: finished piece 1 at 21-OCT-09
piece handle=/u01/app/oracle/backup/WHITE/1ekscnc8_1_1 tag=TAG20091021T205848
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:01:15
channel ORA_DISK_1: starting compressed incremental level 0 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 21-OCT-09
channel ORA_DISK_1: finished piece 1 at 21-OCT-09
piece handle=/u01/app/oracle/backup/WHITE/1fkscngf_1_1 tag=TAG20091021T205848
comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 21-OCT-09
exit;

Vous êtes prêt à effectuer une sauvegarde incrémentale de niveau 1 qui utilisera le fichier créé précédemment. Avant, assurez-vous qu’un checkpoint a été effectué depuis la dernière sauvegarde.

Note:
Si vous enchainez les 2 sauvegardes trop rapidement, vous risquez de rencontrer l’erreur suivante qui indique qu’il n’y a pas de sauvegarde incrémentale à effectuer puisque le checkpoint est identique au checkpoint de la dernière sauvegarde:
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 11/01/2009 10:16:17
ORA-19648: datafile 1: incremental-start SCN equals checkpoint SCN
ORA-19640: datafile checkpoint is SCN 2079819 time 11/01/2009 09:57:19

Pour éviter le phénomène décrit précédemment, connectez vous à la base de données primaire et archivez quelques fichiers de redolog :

. oraenv
sqlplus / as sysdba
ORACLE_SID = [WHITE] ? BLACK
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
sqlplus / as sysdba
alter system archive log current;
alter system archive log current;
alter system archive log current;
exit;

Vous pouvez maintenant réaliser une sauvegarde incrémentale qui utilisera le block change tracking file:

. oraenv
ORACLE_SID = [WHITE] ?
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
rman target /
backup incremental level 1 database;
Starting backup at 01-NOV-09
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=146 device type=DISK
channel ORA_DISK_1: starting compressed incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/WHITE/system01.dbf
input datafile file number=00002 name=/u01/app/oracle/oradata/WHITE/sysaux01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/WHITE/users01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/WHITE/example01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/WHITE/undotbs01.dbf
channel ORA_DISK_1: starting piece 1 at 01-NOV-09
channel ORA_DISK_1: finished piece 1 at 01-NOV-09
piece handle=/u01/app/oracle/backup/WHITE/1vkt8i5g_1_1 tag=TAG20091101T102135 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03
channel ORA_DISK_1: starting compressed incremental level 1 datafile backup set
channel ORA_DISK_1: specifying datafile(s) in backup set
including current control file in backup set
including current SPFILE in backup set
channel ORA_DISK_1: starting piece 1 at 01-NOV-09
channel ORA_DISK_1: finished piece 1 at 01-NOV-09
piece handle=/u01/app/oracle/backup/WHITE/20kt8i6h_1_1 tag=TAG20091101T102135 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01
Finished backup at 01-NOV-09
exit;

Pour vérifier que le fichier est effectivement utilisé, interrogez la vue v$backup_datafile sur la base de données standby :

sqlplus / as sysdba
select set_count,
       used_change_tracking bct,
       used_optimization optzed,
       sum(datafile_blocks) "Blocks",
       sum(blocks_read) "Blocks Reads",
       trunc(sum(blocks_read)/sum(datafile_blocks) * 10000)/100 as "% read"
  from   v$backup_datafile
 group  by set_count, used_change_tracking, used_optimization
 order  by set_count;
 SET_COUNT BCT OPT     Blocks Blocks Reads     % read
---------- --- --- ---------- ------------ ----------
        55 NO  NO      210080            0          0
        56 NO  NO         612            0          0
        57 NO  NO         612            0          0
        59 YES YES     210080       191877      91.33
        60 NO  NO         612          612        100
        63 YES NO      210080          389        .18
        64 NO  NO         612          612        100
exit;

Comme vous pouvez vous en rendre compte, le fichier de suivi des changements des blocs a été utilisé à la fois par la sauvegarde de niveau 0 qui l’a initialisé et la sauvegarde de niveau 1 qui l’a utilisé et modifié.

Perte d’archivelogs et sauvegarde incrémentale

Cette seconde partie répond, à la question suivante avec les nouvelles possibilités offertes par Oracle 11g Release 2 : « Comment remonter une standby après avoir perdu certains fichiers archivelog ? ». Pour cela, il est possible d’utiliser Oracle Recovery Manager et la commande BACKUP DATABASE ... FROM SCN. Notre exemple utilise 2 bases de données avec des db_unique_name et des noms d’instance différents :

BLACK est la base de données/l’instance primaire;
WHITE est la base de données/l’instance standby.

Perdre des fichiers d’archivelogs

Pour supprimer des fichiers d’archivelogs non encore utilisés par la base de données standby, le plus simple est, sans doute, d’arrêter la standby de générer les archivelogs et de les supprimer avant de redémarrer la standby; c’est en substance ce que les scripts ci-dessous réalisent. La première étape consiste donc à arrêter la base de données WHITE en standby :

$ . oraenv
ORACLE_SID = [BLACK] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
sqlplus / as sysdba
shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
exit;

Une fois la standby arrêtée, vous pouvez générer des fichiers archivelogs sur la base de données primaire et les supprimer dans la foulée :

$ . oraenv
ORACLE_SID = [BLACK] ? BLACK
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
$ rman target /
sql 'alter system archive log current';
sql statement: alter system archive log current
sql 'alter system archive log current';
sql statement: alter system archive log current
list archivelog all;
List of Archived Log Copies for database with db_unique_name BLACK
=====================================================================
Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
500     1    271     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_271_699264586.dbf
514     1    272     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_272_699264586.dbf
515     1    273     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_273_699264586.dbf
delete force archivelog sequence between 271 and 273;
released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=23 device type=DISK
List of Archived Log Copies for database with db_unique_name BLACK
=====================================================================
Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
500     1    271     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_271_699264586.dbf
514     1    272     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_272_699264586.dbf
515     1    273     A 31-OCT-09
        Name: /u01/app/oracle/oradata/BLACK/archivelogs/1_273_699264586.dbf
Do you really want to delete the above objects (enter YES or NO)? YES
deleted archived log
archived log file
name=/u01/app/oracle/oradata/BLACK/archivelogs/1_271_699264586.dbf RECID=500
STAMP=701714938
deleted archived log
archived log file
name=/u01/app/oracle/oradata/BLACK/archivelogs/1_272_699264586.dbf RECID=514
STAMP=701715588
deleted archived log
archived log file
name=/u01/app/oracle/oradata/BLACK/archivelogs/1_273_699264586.dbf RECID=515
STAMP=701715592
Deleted 3 objects

Note:
Si vous n’utilisez pas la clause FORCE de la commande DELETE, RMAN découvre que les fichiers sont utiles pour la standby et refuse de les supprimer. Un message comme celui ci-dessous s’affiche :
RMAN-08137: WARNING: archived log not deleted, needed for standby or
upstream capture process archived log file
name=/u01/app/oracle/oradata/BLACK/archivelogs/1_272_699264586.dbf thread=1 sequence=272

Enfin, redémarrez la base de données de standby :

$ . oraenv
ORACLE_SID = [BLACK] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
sqlplus / as sysdba
startup mount
ORACLE instance started.
Total System Global Area  263639040 bytes
Fixed Size		    1335892 bytes
Variable Size		  109055404 bytes
Database Buffers	  146800640 bytes
Redo Buffers		    6447104 bytes
Database mounted.
Database opened.
exit;

Constater le problème

Une fois la base de données redémarrée, la base de données primaire va tenter de renvoyer les fichiers qui manquent à la standby et ainsi résoudre le « GAP » de la base de données standby. La manière la plus simple de découvrir le problème consiste à utiliser dgmgrl comme ci-dessous :

$ . oraenv
ORACLE_SID = [BLACK] ? BLACK
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
connect /
Connected.
show configuration
Configuration - zen
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
      Error: ORA-16724: cannot resolve gap for one or more standby databases
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
exit;

Vous pouvez en savoir un peu plus sur le message d’erreur en regardant le fichier drc<INSTANCE_NAME>.log situé dans le répertoire correspondant au paramètre background_dump_dest. Vous verrez apparaître un message comme celui-ci:

RSM0: HEALTH CHECK ERROR: ORA-16783: cannot resolve gap for database white
Found unresolvable gap to database white.
Operation HEALTH_CHECK canceled during phase 2, error = ORA-16724
Operation HEALTH_CHECK canceled during phase 2, error = ORA-16724

Note à moi-même:
Dand mon cas (Linux x86 & 11.2.0.1), le process MRP reste dans l’état APPLYING_LOG sur la standby. Cela est très probablement une conséquence du changement d’algorithme dans le GAP resolution d’Oracle 11.2 et du fait qu’il n’y a plus besoin de positionner les paramètres FAL_CLIENT et FAL_SERVER. Seule la base primaire détecte le problème et ceci, même si les fichiers archivelogs successifs au redémarrage sont, quant à eux, envoyés sur la standby. Reste que le message sur la primaire n’est pas vraiment explicite puisque (1) on ne sait pas ce qu’il manque et (2) il n’y a pas de message dans le fichier alert.log; seul le broker détecte le-dit problème.

Vérifier ce qui a été appliqué sur la standby

Voila venu le temps de votre intervention ;-). Il faut donc appliquer les modifications perdues avec les fichiers d’archivelogs sur la standby. Pour cela, la première question à laquelle il convient de répondre est donc la suivante : « Où en est la base de données Standby ? ». Interrogez les vues V$DATABASE et V$DATAFILE_HEADER sur la standby. Mais d’abord, arrêtez le processus MRP

 . oraenv
ORACLE_SID = [BLACK] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
sqlplus / as sysdba
alter database recover managed standby database cancel;
Database altered.
select CONTROLFILE_CHANGE# from v$database;
CONTROLFILE_CHANGE#
-------------------
            2023046
select CHECKPOINT_CHANGE# from v$datafile_header;
CHECKPOINT_CHANGE#
------------------
           2023046
           2023046
           2023046
           2023046
           2023046

Effectuer une sauvegarde incrémentale de la base de données primaire (ou une autre standby) :

Pour capturer les changements stockés dans les fichiers archivelog perdu, nous allons effectuer une sauvegarde incrémentale avec la clause from scn comme ci-dessous :

. oraenv
ORACLE_SID = [oracle] ? BLACK
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
rman target /
host 'mkdir -p /u01/app/oracle/backup/BLACK/4standby';
backup incremental from scn 2023046
  to destination '/u01/app/oracle/backup/BLACK/4standby'
  database;
list archivelog from scn 2023046 ;
backup current controlfile
    to destination '/u01/app/oracle/backup/BLACK/4standby';
sql 'alter system archive log current';
backup archivelog from scn 2023046
    to destination '/u01/app/oracle/backup/BLACK/4standby';
exit;

Note:
Si vous avez un fichier bctf sur la base de données primaire et que le SCN est postérieur à la dernière sauvegarde incrémentale, ce fichier peut-être utilisé avec la clause from scn ce qui réduit significativement le temps de cette sauvegarde incrémentale. Pour vérifier que le bctf est utilisé, interrogez v$backup_datafile.used_optimization comme dans la section précédente.

Une fois la sauvegarde effectuée, vous pouvez pousser les fichiers sur votre serveur de standby avec la méthode de votre choix (NFS, scp, …). Une fois les fichiers accessibles depuis la standby, cataloguez les fichiers et appliquez la sauvegarde incrémentale sur la standby :

. oraenv
ORACLE_SID = [BLACK] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
mkdir -p /u01/app/oracle/backup/WHITE/4standby
scp -r black:/u01/app/oracle/backup/BLACK/4standby
      /u01/app/oracle/backup/WHITE/4standby
dgmgrl /
edit database white set state='APPLY-OFF';
exit;
rman target /
catalog start with '/u01/app/oracle/backup/WHITE/4standby';
recover database noredo;
exit

Note:
Il faut arrêtez le process MRP pour pouvoir appliquez le recover sur la standby.

Lorsque le fichier de sauvegarde incrémentale est appliqué sur la base de données standby, le standby controlfile n’est pas modifié, de sorte que le SCN dans ce fichier reste celui d’avant les archivelogs perdus. Dans l’étape ci-dessous, vous utiliserez la commande duplicate, sans se connecter à la target pour recréer le standby standby controlfile et commencer à appliquer les archivelogs :

rman auxiliary /
sql clone 'alter system set dg_broker_start=false';
shutdown clone immediate;
startup clone nomount;
duplicate database for standby
   backup location '/u01/app/oracle/backup/WHITE/4standby'
   nofilenamecheck;
Starting Duplicate Db at 31-OCT-09
contents of Memory Script:
{
   restore clone standby controlfile from
'/u01/app/oracle/backup/WHITE/4standby/BLACK/backupset/2009_10_31/
o1_mf_ncnnf_TAG20091031T222129_5gsbltl3_.bkp';
}
executing Memory Script
Starting restore at 31-OCT-09
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=134 device type=DISK
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/app/oracle/oradata/WHITE/control01.ctl
output file name=/u01/app/oracle/oradata/WHITE/control02.ctl
Finished restore at 31-OCT-09
contents of Memory Script:
{
   sql clone 'alter database mount standby database';
}
executing Memory Script
sql statement: alter database mount standby database
released channel: ORA_AUX_DISK_1
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=134 device type=DISK
contents of Memory Script:
{
   set newname for tempfile  2 to
 "/u01/app/oracle/oradata/WHITE/temp02.dbf";
   switch clone tempfile all;
   set newname for datafile  1 to
 "/u01/app/oracle/oradata/WHITE/system01.dbf";
   set newname for datafile  2 to
 "/u01/app/oracle/oradata/WHITE/sysaux01.dbf";
   set newname for datafile  3 to
 "/u01/app/oracle/oradata/WHITE/undotbs01.dbf";
   set newname for datafile  4 to
 "/u01/app/oracle/oradata/WHITE/users01.dbf";
   set newname for datafile  5 to
 "/u01/app/oracle/oradata/WHITE/example01.dbf";
   restore
   clone database
   ;
}
executing Memory Script
executing command: SET NEWNAME
renamed tempfile 2 to /u01/app/oracle/oradata/WHITE/temp02.dbf in control file
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 31-OCT-09
using channel ORA_AUX_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/31/2009 22:54:42
RMAN-05556: not all datafiles have backups that can be recovered to SCN
consistent
RMAN-03015: error occurred in stored script Memory Script
RMAN-06026: some targets not found - aborting restore
RMAN-06023: no backup or copy of datafile 5 found to restore
RMAN-06023: no backup or copy of datafile 4 found to restore
RMAN-06023: no backup or copy of datafile 3 found to restore
RMAN-06023: no backup or copy of datafile 2 found to restore
RMAN-06023: no backup or copy of datafile 1 found to restore
list archivelog all;
List of Archived Log Copies for database with db_unique_name WHITE
=====================================================================
Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
1       1    277     A 31-OCT-09
        Name: /u01/app/oracle/oradata/WHITE/archivelogs/1_277_699264586.dbf
2       1    278     A 31-OCT-09
        Name: /u01/app/oracle/oradata/WHITE/archivelogs/1_278_699264586.dbf
3       1    279     A 31-OCT-09
        Name: /u01/app/oracle/oradata/WHITE/archivelogs/1_279_699264586.dbf
recover database until sequence 280;
Starting recover at 31-OCT-09
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time: 00:00:01
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=277
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=278
channel ORA_DISK_1: reading from backup piece
/u01/app/oracle/backup/WHITE/4standby/BLACK/backupset/2009_10_31/
o1_mf_annnn_TAG20091031T222143_5gsbm80w_.bkp
channel ORA_DISK_1: piece
handle=/u01/app/oracle/backup/WHITE/4standby/BLACK/backupset/2009_10_31/
o1_mf_annnn_TAG20091031T222143_5gsbm80w_.bkp tag=TAG20091031T222143
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file
name=/u01/app/oracle/oradata/WHITE/archivelogs/1_277_699264586.dbf thread=1
sequence=277
archived log file
name=/u01/app/oracle/oradata/WHITE/archivelogs/1_278_699264586.dbf thread=1
sequence=278
archived log file
name=/u01/app/oracle/oradata/WHITE/archivelogs/1_279_699264586.dbf thread=1
sequence=279
Finished recover at 31-OCT-09
sql 'alter system set dg_broker_start=true';
exit;
ORACLE_SID = [WHITE] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is
/u01/app/oracle
dgmgrl /
edit database white set state='APPLY-ON';

Notes :
Si le broker est activé et que vous démarrez en mode nomount l’instance standby, le controlfile est monté automatiquement; pour cette raison, désactivez le broker pour restaurer le controlfile. Redémarrez le mode apply une fois la base de données standby de nouveau en ligne.
La commande duplicate s’arrête après avoir restauré et changé la configuration (chemins des fichiers) du controlfile puisqu’il n’y a pas de sauvegarde des datafiles. C’est ce que nous cherchons à réaliser.
Une autre solution pourrait consister à recréer un fichier le controlfile à partir d’une commande alter database backup controlfile to trace, puis le transformer en standby controlfile. Toutefois, si les bases primaires et standby sont sur le même serveur, la commande create controlfile échoue. En effet la commande verrouille une ressource sur le serveur pour éviter que plusieurs base de données avec le même nom soient utilisées; dans ce cas très précis, le verrou utilise db_name et non pas uniquement db_unique_name ce qui fait échouer la commande avec le message d’erreur :
ORA-01503: CREATE CONTROLFILE failed
ORA-01158: database  already mounted

Une dernière erreur

Pour une raison que j’ai pas encore élucidée, le processus de transport ne redémarre pas correctement après ces opérations; j’utilise 11.2.0.1 sous Linux x86 ! Vous pouvez vous en apercevoir depuis le broker ou en interrogeant les vues v$managed_standby :

show configuration;
Configuration - zen
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
      Error: ORA-16778: redo transport error for one or more databases
    white - Physical standby database
      Warning: ORA-16826: apply service state is inconsistent with the DelayMins
property
Fast-Start Failover: DISABLED
Configuration Status:
ERROR
exit

Un moyen de contournement simple et qui n’affecte pas la base de données de production consiste à arrêter et redémarrer la base de données standby comme ci-dessous :

. oraenv
ORACLE_SID = [WHITE] ? WHITE
The Oracle base for ORACLE_HOME=/u01/app/oracle/product/11.2.0/db_1 is /u01/app/oracle
sqlplus / as sysdba
startup force mount;
exit;
dgmgrl /
show configuration;
Configuration - zen
  Protection Mode: MaxPerformance
  Databases:
    black - Primary database
    white - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS

Et c’est reparti !

Conclusion

Voilà qui termine officiellement ma série de 5 articles consacrés à Oracle 11g Release 2 Data Guard. Toutefois, comme avec Oracle, on n’en sort jamais vraiment, j’ai commencé une première séquelle qui illustrera la conversion d’une standby physique en standby logique avec le broker. Le contenu de ce qui sera donc l’épisode (6/5) est terminé et illustre également la construction d’une standby avec une commande duplicate sans connexion à la target.
Quant aux possibles séquelles 7/5 et 8/5, j’attends vos commentaires : « Que pensez-vous qu’il soit encore nécessaire d’ajouter et/ou d’explorer à propos d’Oracle Database 11g Release 2 Data Guard ? »

Thomas Bordet

Voir tous ses articles