Problème avec les journaux d'archivelogs

[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 :

RECOVER DATABASE UNTIL ...

Puis :

Code :

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]

Envoyé par 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.

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]

Envoyé par philcero

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...

[orafrance]

Envoyé par philcero

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...

bah non, tu es parti d'une sauvegarde pour réparer ta base, refaire une sauvegarde ensuite ne servirait à rien sauf si la réparation consiste aussi à passer des scripts à la main genre chargement de données

[phil4444]

revenons à nos moutons, donc si j'ai tout compris, j'ai après mon :

Code :

1
2
STARTUP MOUNT;
j'ai fais un RECOVER AUTOMATIC DATABASE;

voici le retour de la commande :

Code :

1
2
3
SQL> recover automatic DATABASE;
ORA-00283: session de rÚcupÚration annulÚe pour cause d'erreurs
ORA-01610: rÚcupÚration Ó l'aide de l'option BACKUP CONTROLFILE Ó exÚcuter

visiblement le recover database ne suffit pas, j'ai donc fait un :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
SQL> recover DATABASE until cancel USING backup controlfile;
ORA-00279: changement 1236274 gÚnÚrÚ Ó 05/14/2008 02:00:02 requis pour thread 1
ORA-00289: suggestion : D:\xxxx\ARCHIVELOG\ARC00003_0654625078.001
ORA-00280: le changement 1236274 pour le thread 1 se trouve au no de sÚquence 3
 
Indiquer le journal : {<RET>=suggÚrÚ | nomfichier | AUTO | CANCEL}
d:\ORAINET\ARCHIVELOG\ARC00003_0654625078.001
ORA-00279: changement 1236515 gÚnÚrÚ Ó 05/14/2008 02:01:23 requis pour thread 1
ORA-00289: suggestion : D:\xxxx\ARCHIVELOG\ARC00004_0654625078.001
ORA-00280: le changement 1236515 pour le thread 1 se trouve au no de sÚquence 4
ORA-00278: le fichier journal 'd:\xxxx\ARCHIVELOG\ARC00003_0654625078.001'
n'est plus nÚcessaire pour cette rÚcupÚration
 
 
Indiquer le journal : {<RET>=suggÚrÚ | nomfichier | AUTO | CANCEL}
d:\xxxx\ARCHIVELOG\ARC00004_0654625078.001
Fichier journal appliquÚ.
RÚcupÚration aprÞs dÚfaillance matÚrielle terminÚe.

Visible c'est mieux

pourquoi le RECOVER AUTOMATIC DATABASE; ne fonctionne pas ???

Une autre question si on est en mode ARCHIVELOG, on peut être appelé à recharger les REDO LOGS courant ? si oui je suppose que c'est la même commande qu'au dessus mais avec le chemin du REDOLOG

A la fin je passe la commande :

ALTER DATABASE OPEN; mais il me demande une option soit RESETLOGS ou NORESETLOGS, comme je ne veux pas recréer les REDO mais utiliser ceux qui existent je choisis NORESETLOGS

Mais là encore il me force à mettre RESETLOGS pfffff!!!!

[phil4444]

uen question me chiffonne, tu dis orafrance, si tous les fichiers ont été restaurés correctement juste un RECOVER DATABASE suffit.
Euhh, ça j'aimerais bien le voirparce que perso, je restaure mes fichiers sauvegardés correctement je pense mais il y a toujours un défaut de synchrone avec les redo

[orafrance]

Je pensais au backup à froid, sinon effectivement il faut indiquer le redo courant

pourquoi le RECOVER AUTOMATIC DATABASE; ne fonctionne pas ???

Et RECOVER DATABASE ? En principe, tout ce que tu as à faire manuellement c'est indiqué le redo courant.

[phil4444]

j'ai lancé une RECOVER DATABASE et c'est pas mieux.
Il demande de passer les option UNTIL CANCEL USING BACKUP CONTROLFILE.
El le pire c'est que je ne vois pas pourquoi.

je simule la perte du fichier control CTL1 en arrêtant la base et en supprimant le fichier contrôle.

ensuite je vais chercher mon fichier sauvegardé, je redémarre en STARTUP et je passe la commande RECOVER DATABASE et rien n'y fait

Suite au RECOVER DATABASE, j'ai une message

ORA-01507 Base de données non montée

[Milo59000]

Salut,

Normalement, lorsque tu perds un controlfile, il te suffit d'arrêter l'instance de copier un autre controlfile et de redémarrer et c'est tout.

Là ton problème est qu'apparement tu dois avoir des ficheirs non synchronisés. Pour régler ce problème, tu dois redémarrer ta base en mode mount puis réaliser les opérations ci-dessous :

Code :

1
2
3
 
RECOVER AUTOMATIC DATABASE USING BACKUP CONTROLFILE;
ALTER DATABASE OPEN RESETLOGS;

Si celà, ne marche pas, c'est qu'il doit te manquer des archived logs ou des redo logs. dans ce cas il faut lancer un

Code :

RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;

Au bout d'un moment, tu devras indiquer le chemin vers tes fichiers REDO LOGS et non plus ARCHIVED LOG !

Sinon, as-tu une sauvegarde à froid ? Si oui, à mon avis le plus simple et que tu la remette en place car j'ai déjà eu le tour une fois ou je n'arrivais plus ç récupérer ma base et j'ai du remettre en place ma sauvegarde.

EDIT : je viens de voir une chose que tu as rajouté dans ton poste précédent :
"Je vais chercher mon fichier sauvegardé"

Voilà pourquoi tes fichiers ne sont pas synchronisés ! Tu confonds deux méthodes j'ai l'impression... la première étant de restaurer un fichier de contrlê qui a été sauvegardé (ce que tu as fait), la deuxième étant la perte d'un fichier de contrôle et pour le récupérer copier un auttre fichier de contrôle.

Tu fais pour moi une grosse erreur de compréhension.

[orafrance]

Envoyé par phil4444

je simule la perte du fichier control CTL1 en arrêtant la base et en supprimant le fichier contrôle.

et tous tes ctl ont la même date de dernière modifs ? Tu fait bien un STARTUP et SHUTDOWN IMMEDIATE avant la copie des ctl ?

[Milo59000]

Je viens de faire le test et oui tu dois bien te tromper.

J'ai trois fichiers de contrôle : control01.ctl, control02.ctl et control02.ctl.

Je supprime control01.ctl en faisant

Code :

rm control01.ctl

j'arrête ma base en faisant un shutdown abort puis je copie une autre controlfile et NON PAS UN CONTROLFILE SAUVEGARDE :

Code :

cp control02.ctl control01.ctl

Je fais un STARTUP et ca marche...

[phil4444]

pour répondre à orafrance oui je fais un shutdown immediate et je supprime le CTL1.

sinon pour répondre à milo je prends mon fichier CTL1 sauvegardé et je replace celui perdu dans le répertoire de la base, c'est peut être là mon erreur.

Pour tout dire je suis entrain de scripter une restauration compléte de la base.

[Milo59000]

Oui, donc c'est bien ca ton erreur ^^

Tu ne remplaces pas le fichier de contrôle perdu par un autre fichier de contrôle déjà en place mais par celui sauvegardé. De ce fait, le ficheir sauvegardé que tu as remis en place et les fichiers de données ainis que les autres fichiers de contrôle ne sont pas synchronisés.

CQFD !

Le fait que tu doives faire une récupération est donc tout à fait normal.

[phil4444]

par-contre dans le cas ou je restaure une base compléte normalement je recopie les fichiers et je joue les journaux et redo.

1) copie des fichiers de la base CONTROLFILE, DATAFILE, etc
2) tentative de connexion sqlplus
3) startup mount
4) RECOVER DATABASE
5)ALTER DATABASE OPEN

ça doit suffir ?

[Milo59000]

Normalement oui.

Le mieux est encore le recover automatic database comme cela Oracle prend tous seul les fichiers à appliquer. Mais il se peut qu'il bloque en cherchant une séquence et généralement il faut indiquer le chemin et le nom du redo log courant.

[orafrance]

Envoyé par phil4444

pour répondre à orafrance oui je fais un shutdown immediate et je supprime le CTL1.

la question était : est-ce que tu fais un shutdown immediate avant de copier le ctl ?

Envoyé par Milo59000

O
Tu ne remplaces pas le fichier de contrôle perdu par un autre fichier de contrôle déjà en place mais par celui sauvegardé.

Ha bah oui, évidemment