Restauration d’un standby controlfile sous ASM

Suite à une erreur liée au chiffrement Transparent Data Encryption (TDE) sur une base Active Standby, j’ai été amené à devoir restaurer un standby controlfile sur cette celle-ci pour tenter de corriger le problème, je reviendrai là-dessus dans un prochain article.

A priori, l’opération peut sembler simple, mais lorsque la base est stockée dans ASM, les choses peuvent devenir plus compliquées que ce que l’on trouve documenté habituellement.

Je vais vous présenter les opérations à effectuer, dans le cas où la base primaire possède à la fois des datafiles Oracle Managed Files (OMF) créés par Oracle et des datafiles créés avec un nom explicite, par exemple :

  • Ajout d’un datafile OMF au tablespace IDX :
ALTER IDX add datafile '+DATA' size 1G;

Ceci crée 1 datafile OMF sous ce nom : ‘+DATA/DB1/datafile/idx.720.1010254353′

  • Ajout d’un datafile au tablespace IDX (non OMF) :
ALTER TABLESPACE IDX add datafile '+DATA/DB1/idx_01.dbf' size 1G;

Dans le second cas, un fichier OMF est également créé avec idx_01.dbf comme alias; néanmoins, dans ce cas, c’est l’alias qui enregistré dans les controlfiles et cela va faire la différence comme nous allons le voir.

 

Tout d’abord, il faut créer un nouveau  standby controlfile à partir de la base primaire sous SQL*PLUS :

PRIM>ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby_control.ctl';

Transférer ce controlfile sur le serveur de la base standby sous /tmp, par exemple :

scp /tmp/standby_control.ctl oracle@STBY:/tmp

Avant de pouvoir restaurer ce controlfile sur base standby, il faut stopper le recovery, process MRP0, redémarrer la base en NOMOUNT (sur une seule instance). Il est préférable que les 2 bases primaire et standby soient synchronisées au préalable :

PRIM> alter system switch logfile;
STBY> select * from v$dataguard_stats;
STBY> alter database recover managed standby database;
STBY> shutdown
STBY> startup nomount

On peut maintenant restaurer ce standby controlfile avec RMAN sur la base standby :

export ORACLE_SID=STBY
rman target /
RMAN>restore controlfile from '/tmp/standby_control.ctl';
Starting restore at 18-JUN-19
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=101 instance=STBY device type=DISK

channel ORA_DISK_1: copied control file copy
output file name=+DATA/STBY/control01.ctl
output file name=+FRA/STBY/control02.ctl
Finished restore at 18-JUN-19

Le controlfile étant restauré, il ne reste plus qu’à modifier les chemins des datafiles. En effet, dans ASM, celui-ci est généralement différent entre la base primaire et la standby, ne serait-ce qu’au niveau du DB_UNIQUE_NAME.

Il faut donc mettre à jour le controlfile avec les chemins correspondant à la base standby au lieu de ceux de la base primaire, et donc recataloguer ceux-ci avec RMAN. La base doit pour cela être à l’état MOUNT :

RMAN> shutdown
database dismounted
Oracle instance shut down
RMAN> startup mount
connected to target database (not started)
Oracle instance started
database mounted

On peut ensuite lancer la commande catalog start sur la racine du répertoire ASM contenant les datafiles :

RMAN> catalog start with '+DATA/STDBY/';

searching for all files that match the pattern +DATA/STDBY/
searching for all files in the recovery area
cataloging files...
cataloging done
List of Files Unknown to the Database
=====================================
File Name: +DATA/STBY/spfileSTBY.ora
File Name: +DATA/STBY/DATAFILE/TOOLS.274.1003421033
File Name: ++DATA/STBY/DATAFILE/IDX.803.1011544441
...
Do you really want to catalog the above files (enter YES or NO)?Y

Malheureusement, cette commande ne recherche et ne catalogue que les datafiles situés sous le répertoire +DATA/STDBY/datafile et si il y a des datafiles qui ont été créés avec 1 alias directement, ceux-ci ne seront pas découverts et mis à jour dans le controlfile.

Si l’on se contente de cataloguer seulement ces datafiles , la commande switch database to copy  sortira en erreur :

RMAN>switch database to copy;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of switch to copy command at 18/06/2019 18:03:03
RMAN-06571: datafile 1 does not have recoverable copy

Pour cataloguer aussi les alias, il faut les spécifier explicitement , pour en obtenir la liste la commande RMAN « report schema »  est utile :

RMAN> report schema;

using target database control file instead of recovery catalog
Report of database schema for database with db_unique_name LPTDWHMT_OCLGIMHHP0D

List of Permanent Datafiles
===========================
File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1 4096  SYSTEM *** +DATA/STBY/system_01.dbf
2 33990 SYSAUX *** +DATA/STBY/sysaux_01.dbf
3 8192  UNDO1  *** +DATA/STBY/undo_01.dbf
4 4096  TOOLS  *** +DATA/STBY/DATAFILE/TOOLS.274.1003421033
5 6144  IDX    *** +DATA/STBY/IDX_01.dbf
6 6144  IDX    *** +DATA/STBY/DATAFILE/IDX.803.1011544441

Et cataloguer les alias des datafiles des  tablespaces SYSTEM,SYAUX,UNDO  ainsi que  le  datafile 1  du tablespace IDX :

RMAN>catalog datafilecopy '+DATA/STBY/system_01.dbf'
RMAN>catalog datafilecopy '+DATA/STBY/sysaux_01.dbf'
RMAN>catalog datafilecopy '+DATA/STBY/undo_01.dbf'
RMAN>catalog datafilecopy '+DATA/STBY/idx_01.dbf'

Et lorsque tous les datafiles ont été catalogués, basculer sur ceux-ci dans le controlfile :

RMAN>switch database to copy;

datafile 1 switched to datafile copy "+DATA/STBY/system_01.dbf"
datafile 2 switched to datafile copy "+DATA/STBY/sysaux_01.dbf"
datafile 3 switched to datafile copy "+DATA/STBY/undo_01.dbf"
datafile 4 switched to datafile copy "+DATA/STBY/DATAFILE/TOOLS.274.1003421033"
datafile 5 switched to datafile copy "+DATA/STBY/IDX_01.dbf"
datafile 6 switched to datafile copy "+DATA/STBY/DATAFILE/IDX.803.1011544441"

Les tempfile ne demandent pas d’actions particulières.

On peut ensuite réactiver la synchronisation de la base standby :

alter database recover managed standby database disconnect;

Laisser un commentaire

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