ORA-00905 sur un recover database

Bonjour, suite à des clusters défectueux, ma base oracle s'est arreté brutallement, perdant le dernier redolog.
J'ai changé les disques et j'essaye de la redémarrer.

j'ai voulu la redémarrer à partir d'un SCN précis:

Code:

---

1 2 3 4 5 6 7 8

startup mount; RECOVER DATABASE AUTOMATIC UNTIL SCN 1,1775E+12; je reçois le message suivant: ORA-00905: Mot-cle absent   recover database automatic UNTIL TIME '2007-11-26 14:19:00'; recover database automatic until CANCEL USING BACKUP CONTROL FILE; ORA-00905: Mot-cle absent

---

Je ne vois pas mon erreur, j'oubli de préciser quelque chose?

merci de votre aide.
M

Citation:

---

Envoyé par moi26

...
RECOVER DATABASE AUTOMATIC UNTIL SCN 1,1775E+12;
je reçois le message suivant:
ORA-00905: Mot-cle absent

---

C'est plutôt : recover automatic database until change NNN;
en ayant récupéré au préalable le NNN dans v$archived_log

select first_change#-1
from v$archived_log
where sequence#=<le_scn>;

Je ne crois pas qu'"automatic" puisse être employé avec until.
Je verrais plutôt :

Code:

---

RECOVER DATABASE UNTIL TIME '2007-11-26 14:19:00' USING BACKUP CONTROLFILE

---

ou bien avec le scn :

Citation:

---

RECOVER DATABASE UNTIL CHANGE 1,1775E+12 USING BACKUP CONTROLFILE;

---

Citation:

---

Envoyé par moi26

j'oubli de préciser quelque chose?

---

oui ! la version de la base de données :?

bonjour, désolé pour l'attente.
Je suis en 9.2.0.4.0

j'ai essayé

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

recover automatic database until change 1177502988184; 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   RECOVER DATABASE UNTIL CHANGE 1177502988184 USING BACKUP CONTROLFILE; ORA-00279: changement 1179110133029 généré à 12/03/2007 09:39:26 requis pour thr ead 1 ORA-00289: suggestion : /u01/oracle/product/9.2.0/dbs/arch1_183.dbf ORA-00280: le changement 1179110133029 pour le thread 1 se trouve au no de séque nce 183   RECOVER DATABASE UNTIL TIME '2007-11-26 14:19:00' USING BACKUP CONTROLFILE donne: ORA-00279: changement 1179110133029 généré à 12/03/2007 09:39:26 requis pour thread 1 ORA-00289: suggestion : /u01/oracle/product/9.2.0/dbs/arch1_183.dbf ORA-00280: le changement 1179110133029 pour le thread 1 se trouve au no de séquence 183

---

bref, vos solutions n'ont pas marchées.
a chaque fois, il veut la dernierè séquence, la 183.

D'autre idées?

il faut restaurer le redolog où se trouve le change 183 d'abord.

Que donne le résultat de la requête suivante (nécessite que la la base soit dans l'état MOUNT):

Code:

---

1 2	select recid, sequence#, status, first_time, next_time from v$archived_log where first_time > to_date('03/12/2007','DD/MM/YYYY');

---

Quels sont les fichiers que vous avez restaurés et de quand date la sauvegarde des fichiers restaurés ? Si Oracle demande l'accès à un archive log du 3 décembre et que vous voulez restaurer à l'état du 26 novembre, c'est probablement parce que vous avez restauré des fichiers sauvegardés autour du 3 décembre. Pour restaurer la base à l'état du 26 novembre, il faut partir d'une sauvegarde de la base antérieure au 26 novembre (et non postérieure).

La requette ne donne aucun résultat.
j'ai choisi de restaurer ma base en date du 26/11 car c'est mon unique sauvegarde avec des fichiers corrects. Les autres dates, la sauvegarde des fichiers a planté car elle est tombée sur des clusteurs défecteux.

Pour le redo log, sa taille normale est de 100Mo
je ne peux récupérer cette taille que le 26/11. Le 03/12, ce fichier ne fait que 15Mo.
Bref, si je restaure en date du 03, mon fichier redo ne sera pas complet.

Mon but n'est pas de restaurer à une date précise, mais juste d'ouvrir la base:
je dois juste récupérer un package crée en mars dans cette base .

merci pour votre aide.

si je fait:

recover database until time '2007-12-03 14:19:00' USING BACKUP CONTROLFILE;

j'obtiens la réponse suivante:
ORA-00279: changement 1179110133029 généré à 12/03/2007 09:39:26 requis pour thread 1.

qu'est ce que ça donne si je restaure avec le numéro 1179110133028?
j'évite le probleme?

S'il n'y a aucune trace dans V$ARCHIVED_LOG du n° de séquence demandé, Oracle demande non un archive log mais en fait un redo log courant. Vous pouvez essayer de donner le nom d'un membre de chaque groupe des online redo logs à la place du nom d'un archive log que vous pouvez obtenir avec:

Code:

---

select member from v$logfile;

---

Mais si les redo logs courants sont cassés, il n'y a pas vraiment de solution supportée.

oui, il demande le redolog2 qui a normalement la séquence 183
Quand j'ai restauré le redolog2 en date du 26/11, il contenanait la séquence 178.
Je ne peux restaurér la 183 car contenait tropn de cluster defectueux.
Pour résumer:
j'ai toutes les dernieres séquences sauf la toute dernieres (183) qui était dans mon redolog2. Redolog que je ne peux restaurer car trop de secteur défecteux.

comment faire pour ouvrir la base à n'importe quel numéro de séquence?

tes redologs n'étaient pas multiplexés?

Bonjour, désolé pour le délai mais j'ai du avancer sur d'autre points.

Non, les redo logs n'était pas multiplexé.
En regardant le fichier alert/log, j'ai vu que la séquence manquante (la 183) a été crée le 03/12, soit le jour du crash de la base.

Comment puis-je relancer la base avec la séquence 182?

que donne le résultat de la requête

Code:

---

select * from v$log

---

Voilà un extrait d'un document Metalink (Recover database after disk loss
Doc ID: Note:230829.1)

Citation:

---

(B) Redo logs
---------
In normal cases, we would not have backups of online redo log files. But the
inactive logfile changes could already have been checkpointed on the datafiles
and even archive log files may be available.

SQL> startup mount
Oracle Instance Started
Database mounted
ORA-00313: open failed for members of log group 1 of thread 1
ORA-00312: online log 1 thread 1: '/ORACLE/ORADATA/H817/REDO01.LOG'
ORA-27041: unable to open file
OSD-04002: unable to open file
O/S-Error: (OS 2) The system cannot find the file specified.

** Verify if the lost redolog file is Current or not.
SQL> select * from v$log;
SQL> select * from v$logfile;

--> If the lost redo log is an Inactive logfile, you can clear the logfile:

SQL> alter database clear logfile '/ORACLE/ORADATA/H817/REDO01.LOG';

Alternatively, you can drop the logfile if you have atleast two other
logfiles:
SQL> alter database drop logfile group 1;


--> If the logfile is the Current logfile, then do the following:
SQL> recover database until cancel;

Type Cancel when prompted

SQL>alter database open resetlogs;


The 'recover database until cancel' command can fail with the following
errors:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error
below
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/ORACLE/ORADATA/H817/SYSTEM01.DBF'

In this case , restore an old backup of the database files and apply the
archive logs to perform incomplete recovery.
--> restore old backup
SQL> startup mount
SQL> recover database until cancel using backup controlfile;
SQL> alter database open resetlogs;


If the database is in noarchivelog mode and if ORA-1547, ORA-1194 and ORA-1110 errors occur, then you would have restore from an old backup and start the database.


Note that all redo log maintenance operations are done in the database mount state

---

Tu peux essayer de t'en inspirer

select * from v$log:

FIRST_CHANGE# FIRST_TI
------------- --------
1 1 182 104857600 1 NO INACTIVE
1,1791E+12 26/11/07

2 1 183 104857600 1 NO CURRENT
1,1791E+12 03/12/07

3 1 179 104857600 1 NO INACTIVE
1,1775E+12 20/11/07


GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TI
------------- --------
4 1 180 104857600 1 NO INACTIVE
1,1775E+12 20/11/07

5 1 181 104857600 1 NO INACTIVE

:? tu pourrais essayer s'il te plait de formater un peu le résultat de ta requête pour qu'on voie le first change# autrement qu'avec des exposants.

pardon, vraiment désolé, je n'y ai pas du temps pensé. Voici le résultat au bon format:

Code:

---

1 2 3 4 5 6 7

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TI ---------- ---------- ---------- ---------- ---------- --- ---------------- ------------------- -------- 1 1 182 104857600 1 NO INACTIVE 1179109830514 26/11/07 2 1 183 104857600 1 NO CURRENT 1179110133029 03/12/07 3 1 179 104857600 1 NO INACTIVE 1177503322471 20/11/07 4 1 180 104857600 1 NO INACTIVE 1177503344402 20/11/07 5 1 181 104857600 1 NO INACTIVE 1177503364622 20/11/07

---

Bonjour,

Je pense qu'il faut que tu tentes en mode mount un recover until change 1179110133028 (c'est à dire au numéro immédiatement inférieur au numéro du first change du redo perdu) à partir d'une sauvegarde complète et cohérente (juste inférieure au crash). C'est bien ce que tu voulais tenter d'ailleurs
Les spécialistes nous aideront et me corrigeront... (je ne fais pas beaucoup de recovery crash:oops:)
Dis-nous ce que ça donne