Discussion :

[phil4444]

j'ai crashé volontairement ma base pour tester une restauration.
pour se faire j'ai arrêté le service de l'instance sous mon serveur windows.
et j'ai supprimé le fichier CONTROLFILE CTL01.
j'ai donc redémarré ma base en faisant un startup mount
il m'a signalé l'erreur du fichier de CONTROL, j'ai donc copié CTL3 en CTL1 comme indiqué.
Ensuite j'ai fais un ALTER DATABASE OPEN RESETLOGS;
il m'a indiqué qu'il y avait une erreur de séquence il demandait une séquence 51 requise alors qu'il avait une 50, hors dans mon archive log list j'avais pas plus que la séquence 50.
j'ai donc fais un RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE et ensuite j'ai passé mon répertoire en paramètre du fichier demandé, j'avais toujours l'erreur.
j'ai fais machinalement un ALTER DATABASE OPEN RESETLOGS; et là en message de retour j'ai la base a été modifiée et ça semble être rentré dans l'ordre, mais je ne sais pas pourquoi

[orafrance]

parce que tu n'as pas indiqué le redo courant, du coup en faisant un RECOVER UNTIL CANCEL tu t'arrêtes à la dernière archive et tu peux donc faire un RESETLOGS, c'est à dire recréer les redos.

[philcero]

Si je ne me trompe pas, une remise en état de base, outre les réparations annexes, passe toujours par l'enchaînement de deux commandes.

En premier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RECOVER DATABASE UNTIL ...

Puis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ALTER DATABASE OPEN RESETLOGS;

Il suffisait juste de les entrer dans le bon ordre.

En fait la première commande va permettre à Oracle de s'appuyer non seulement sur les ARCHIVE LOGS mais également sur les contenu du dernier REDO LOG courant afin de terminer sa remise en état.

[orafrance]

Si je ne me trompe pas, une remise en état de base, outre les réparations annexes, passe toujours par l'enchaînement de deux commandes.

Surement pas toujours

Si tu as restauré tous les fichiers comme il faut alors un simple RECOVER DATABASE suivi d'un ALTER DATABASE OPEN suffit... heureusement que le RESETLOG n'est pas toujours obligatoire

[philcero]

le RESETLOG n'est pas toujours obligatoire

Partant du principe que le RESETLOG va simplement amener une cassure dans la génération des archives qui provoquera de facto une nouvelle incarnation de la base cela ne me pose pas plus de problèmes que ça de le généraliser.

Dans ma façon de voir les choses une base réparée doit également être immédiatement arrêtée et sauvegardée de façon fiable afin d'amener un point de rupture à ce niveau là également.

Bien entendu cette petite manipulation supplémentaire doit être prise en compte dans le calcul du SLA...

[orafrance]

Partant du principe que le RESETLOG va simplement amener une cassure dans la génération des archives qui provoquera de facto une nouvelle incarnation de la base cela ne me pose pas plus de problèmes que ça de le généraliser.

Pourvu qu'il soit possible de refaire une FULL derrière ce qui n'est pas toujours évident compte tenu des volumétries et que tu ne pratiques pas de réplication (genre standby ).

Créer une nouvelle incarnation est tout sauf anodin... quand à faire une sauvegarde après la restauration d'une précédente sauvegarde, je ne vois pas bien l'intérêt si ce n'est avoir 2 fois la même sauvegarde avec 2 incarnation différentes

[philcero]

quand à faire une sauvegarde après la restauration d'une précédente sauvegarde, je ne vois pas bien l'intérêt si ce n'est avoir 2 fois la même sauvegarde avec 2 incarnation différentes

Attention, je parle de sauvegarder la base une fois réparée. Dans notre cas, la précédente est forcément dans un état tout autre...