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;
