Quand et comment restaurer les controfiles
- Détails
- Catégorie : Backup/Restore
- Publié le jeudi 21 février 2013 21:13
- Écrit par Administrator
- Affichages : 20542
Quand une base ne démarre pas, car il semble qu’il y ait une corruption ou des fichiers manquant, avant de se lancer dans une restauration totale de la base, une petite analyse peut faire gagner un temps précieux, surtout quand la base fait dans le 1To ou plus.
Dans cet article nous allons voir les différents cas qui nécessitent la restauration du « petit » fichier controlfile. Cet article s'applique pleinement sur la version 11gR2 d'Oracle.
Mais avant de commencer, un petit rappel : multiplexez toujours vos controlfiles. Cela ne coûte rien, et même si vous les mettez au même emplacement, au moins vous éviterez une restauration en cas de corruption d’un controlfile comme nous allons le voir plus bas. Personnellement je les multiplexe toujours en 3 versions et si possible dans 3 emplacements (axe) différents.
Perte ou corruption d’un controlfile multiplexé
Controlfile sur filesystem
Au démarrage de la base vous obtenez le message 
:
ORA-00205: error in identifying control file, check alert log for more info
Vous avez au moins un controlfile manquant ou corrompu. En plus de 10 ans de carrière, j’ai dû rencontrer ce message 4 ou 5 fois, et à chaque fois, heureusement, les controfiles étaient multiplexés, ce qui simplifie grandement la résolution du problème.
Il y a donc au moins un controfile absent ou corrompu, mais lequel ? Pour cela ouvrez l'alert.log:
ALTER DATABASE MOUNT
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/oradata/TESTORA/control01.ctl'
ORA-27046: file size is not a multiple of logical block size
Additional information: 1
Une fois le controlfile posant problème identifié, connectez vous sur la base qui est en "nomount", pour localiser l'emplacement de tous vos controlfiles, puis tombez la base:
SQL> show parameter control
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string /oradata/TESTORA/control01.ctl , /oradata/FRA/TESTORA/control02.ctl
SQL>shutdown abort ;
Copiez alors un controlfile sain à l'emplacement du corrompu:
# cd /oradata/TESTORA/
# mv control01.ctl control01.ctl.OLD
# cp /oradata/FRA/TESTORA/control02.ctl control01.ctl
Et voilà problème résolu, pas la peine de se lancer dans une restauration. Il suffit d'ouvrir la base avec un bon "startup" des familles! 
Controlfile sur ASM
Bon maintenant le même cas mais avec asm. Là c’est un peu plus compliqué. Bien sûr la commande cp existe sous asm, mais en fait elle fait un lien à l’emplacement qu’on lui a spécifié et fait plein de chose qu’on ne lui demande pas. Je m'explique:
ASMCMD [+DATA1/ARKONA/CONTROLFILE] > ls
Current.256.806278451
ASMCMD [+DATA1/ARKONA/CONTROLFILE] > cp Current.256.806278451 controlfile.ctl
copying +DATA1/ARKONA/CONTROLFILE/Current.256.806278451 -> +DATA1/ARKONA/CONTROLFILE/controlfile.ctl
La commande a créé un alias à la place du fichier controlfile.ctl indiqué et comme elle a vu que c’était un controlfile, le fichier a été créé dans <+DISKGROUP>/ASM/CONTROFILE. D'ailleurs si j'exécute un ls sur mon "nouveau" fichier controlfile, j'obtiens:
ASMCMD [+DATA1/ARKONA/CONTROLFILE] > ls -l
Type Redund Striped Time Sys Name
CONTROLFILE HIGH FINE FEB 21 20:00:00 Y Current.256.806278451
N controlfile.ctl => +DATA1/ASM/CONTROLFILE/controlfile.ctl.268.808001217
Donc comme précédemment nous démarrons la base et obtenons l’erreur ORA-00205, puis dans l’alert.log nous identifions le controfile posant problème :
ORA-00210: cannot open the specified control file
ORA-00202: control file: '+DATA1/arkona/controlfile/current.256.806278451'
ORA-17503: ksfdopn:2 Failed to open file +DATA1/arkona/controlfile/current.256.806278451
ORA-15012: ASM file '+DATA1/arkona/controlfile/current.256.806278451' does not exist
Puis localisons les controfiles:
SQL> show parameter control_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string +DATA1/arkona/controlfile/current.256.806278451, +DATA2/arkona/controlfile/current.256.806278451
A partir de là la méthode diverge par rapport à la précédente sur filesystem. Ici nous changeons le chemin du controfile corrompu dans le paramètre control_files, nous le mettons à la racine du diskgroup (pour pouvoir utiliser OMF). Puis la base est tombée et démarrée en nomount:
SQL> alter system set control_files='+DATA1','+DATA2/arkona/controlfile/current.256.806278451' scope=spfile;
SQL> shutdown abort
SQL> startup nomount
SQL> exit
Puis nous restaurons les controlfiles à partir du controlfile sain sous RMAN:
# rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Thu Feb 21 21:21:29 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ARKONA (not mounted)
RMAN> restore controlfile from '+DATA2/arkona/controlfile/current.256.806278451';
Starting restore at 21-FEB-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=36 instance=ARKONA1 device type=DISK
channel ORA_DISK_1: copied control file copy
output file name=+DATA1/arkona/controlfile/current.256.808003327
output file name=+DATA2/arkona/controlfile/current.256.806278451
Finished restore at 21-FEB-13
Il ne reste plus qu'à ouvrir monter et ouvrir la base:
RMAN> sql 'alter database mount';
RMAN> sql 'alter database open';
Et quand nous vérifions le paramètre control_files... surprise 
:
SQL> show parameter control_files
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
control_files string +DATA1/arkona/controlfile/current.256.808003327, +DATA2/arkona/controlfile/current.256.806278451
La base a automatiquement mis à jour le paramètre control_files avec le nouveau nom du controlfile. Cela a fonctionné car nous avions un spfile et pas un pfile classique.
Si jamais vous aviez un pfile vous auriez dû le faire manuellement dans le pfile. C'est-à-dire après la restauration, vous auriez fait un shutdown abort, modifié le pfile avec le nouveau nom et redémarré la base. Mais normalement si vous êtes sous ASM, j'ose imaginer que vous n'utilisez plus de pfile
.
Perte de tous les controlfiles
Pas de chance tous les controlfiles sont perdus, car un administrateur système
a vu des fichiers control.ctl sur le serveur et il s’est dit c’est quoi ça ? ça sert à rien ? poubelle !
Ou bien, vous pensiez que multiplexer les controlfiles c’est un conseil pour les paranos, la corruption cela n’arrive qu’aux autres.
… à moins que ce ne soit le stagiaire, cela ne serait pas sa première bourde
... ni sa dernière.
Comme précédemment, identification dans l'alert.log:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/oradata/FRA/TESTORA/control02.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/oradata/TESTORA/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Sauf qu'ici ce sont tous les controlfiles qui posent problème.
Il faut donc falloir faire une restauration RMAN avec un backup de controfile.
Si base vous avez une base catalog:
# rman target /
RMAN> connect catalog rman_user/rman_pass@rmandb
RMAN> startup nomount;
RMAN> restore controlfile;
Si vous utilisez uneFlash recovery area:
# rman target /
RMAN> startup nomount;
RMAN> restore controlfile from autobackup;
Sinon, il faut le nom du dernier backup controfile (ou bien le DBID et l'emplacement des vos backups)
# rman target /
RMAN> startup nomount;
RMAN> restore controlfile from '/oradata/backup/TESTORA/cfc-630020041-20130221-00';
Starting restore at 21-FEB-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oradata/TESTORA/control01.ctl
output file name=/oradata/FRA/TESTORA/control02.ctl
Finished restore at 21-FEB-13
Maintenant, il faut lancer un recovery
RMAN> sql 'alter database mount';
RMAN> recover database;
Starting recover at 21-FEB-13
Starting implicit crosscheck backup at 21-FEB-13
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
Crosschecked 3 objects
Finished implicit crosscheck backup at 21-FEB-13
Starting implicit crosscheck copy at 21-FEB-13
using channel ORA_DISK_1
Finished implicit crosscheck copy at 21-FEB-13
searching for all files in the recovery area
cataloging files...
no files cataloged
using channel ORA_DISK_1
starting media recovery
archived log for thread 1 with sequence 29 is already on disk as file /oradata/TESTORA/redo02.log
archived log file name=/oradata/TESTORA/redo02.log thread=1 sequence=29
media recovery complete, elapsed time: 00:00:00
Finished recover at 21-FEB-13
Et là il n’y a pas le choix, même si la restauration peut être considérée comme complète : les derniers journaux en ligne (redolog) ont été rejoués. Et même si d’ailleurs aucun datafile n’a été restauré : nous n’avons exécuté que la commande recover, nous devons obligatoirement faire un resetlog.
Cela est dû au fait que les controfiles restaurés n’ont pas le même SCN que tous les autres fichiers de la base de donnée.
SQL> alter database open RESETLOGS;
Et comme vous le savez, après un resetlog, il faut obligatoirement faire un backup full de votre base... évidement