Discussion :

[moi26]

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 :

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

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

[13thFloor]

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

[Heaven93]

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

Code :

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

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

ou bien avec le scn :

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

[orafrance]

j'oubli de préciser quelque chose?

oui ! la version de la base de données

[moi26]

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

j'ai essayé

Code :

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

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?

[Heaven93]

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

[pifor]

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

Code :

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

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');

[pifor]

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

[moi26]

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.

[moi26]

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?

[pifor]

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 :

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

select member from v$logfile;

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

[moi26]

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?

[Heaven93]

tes redologs n'étaient pas multiplexés?

[moi26]

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?

[Heaven93]

que donne le résultat de la requête

Code :

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

select * from v$log

[Heaven93]

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

(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

[moi26]

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

[Heaven93]

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.

[moi26]

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

Code :

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

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

[Heaven93]

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)
Dis-nous ce que ça donne