Le paramètre caché _allow_resetlogs_corruption

Administration Oracle, Divers, Rman, scripts et trucs Ajouter un commentaire

Dans cet article nous allons voir un exemple de récupération de données après restauration et quand la base ne veut quand même pas s’ouvrir.

Par exemple un disque lâche sur le serveur et on perd le datafile présent dessus, pour restaurer convenablement ce datafile, il nous faut les archives générées entre le dernier backup et le crash mais il nous manque les archives en question. On ne peut donc plus ouvrir la base et manque de chance, ce datafile contient des tables super importantes.

On sait pertinemment que l’on va perdre des données mais on aimerait en perdre le moins possible quitte à utiliser des moyens “spéciaux” pour cela.

A cause de l’intégrité faussée de la base, on ne peut plus l’ouvrir normallement.

Le paramètre caché qui permet de démarrer la base soit en mode  désynchronisée c’est à dire avec au moins un de ses entêtes de datafiles incorrect soit parce qu’on a  endommagé un ou plusieurs redo logs ou encore parce qu’il nous manque une archive ou deux pour restaurer un datafile est _allow_resetlogs_corruption.

Dans le cas ou votre datafile contiendrait des données type index ou que l’on peut facilement recréer, le mieux serait toujours de dropper le tablespace, puis de le recréer / recharger mais dans le cas ou les données ne sont pas facilement reconstructibles quoi faire?

L’idée à suivre pourrait être la suivante :

Restaurer le datafile ou la base à partir du dernier backup.

Jouer les archives jusqu’au dernier numéro de séquence correct (pour cela regarder dans rman : list backup of archivelog all).

Arrêter et redémarrer l’instance avec le paramètre _allow_resetlogs_corruption = TRUE.

Exporter les données souhaitées.

Restaurer la base à partir du dernier backup.

Mettre le datafile offline.

Dropper et recréer le tablespace.

Réimporter les données “récupérées”. Vous risquez néanmoins d’avoir des décalages applicatifs selon les cas, vous n’êtes donc peut être pas exempt de correction des données.

Re backuper la base correctement.

Dans notre cas, la base refuse de s’ouvrir après une restauration RMAN.

la restauration until logseq s’est bien passée, le recover database aussi. Il n’y a qu’au moment d’ouvrir la base en open resetlogs que la base réclame “une récupération de données après défaillance matérielle”.

Ceci à cause d’un datafile dont la mise offline ne s’était pas déroulé correctement.

J’ai donc remis ce datafile online, redémarré avec le paramètre _allow_resetlogs_corruption à TRUE qui a permis de corriger l’entête du fichier.

Puis on arrête la base et on la redémarre normalement.

BEMOL & RESTRICTION : Oracle ne maintient les bases qui ont été démarrées avec ce paramètre, elles sont potentiellement corrompues. C’est donc en dernier ressort et dans le cas désespérés qu’il faut l’utiliser et tout de suite après exporter les données et les réimporter dans une belle base toute neuve.

Alban le punk

Faire un commentaire