Discussion :

[novice_oracle]

Bonjour,
on travail sous oracle 9i, platforme hpux.
on essayant de faire des tests de restaurations des fichiers .dbf dans des repertoires de tests, nous nous sommes trompés et on les a restaurés dans leurs emplacement d'origines.
les fichiers de données .dbf on etaient ecrasés par des anciens, mais les fichiers index correspondant sont les recent, on les a pas touchés et on a pas une sauvegarde des fichiers index correspondant aux anciens.
apparement y'a pas de corespondance entre les fichiers .dbf et les fichiers index.
depuis ce probléme, la base ne veux pas démarrer et on peux pas y acceder pour essayer de regler le probléme.

que faire pour demarrer la base ??????

[LeoAnderson]

Donc, vous avez des fichiers .dbf de data à la date X et des fichiers .dbf correspondants aux indexes à la date Y?

En tous les cas, merci de donner le message d'erreur exact renvoyé par la commande

Code :

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

startup

ou

Code :

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

alter database mount;

ou

Code :

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

alter database open;

selon l'état actuel de la abse (closed, no mount ou mount) ainsi que les messages se trouvant dans l'alert.log.

[novice_oracle]

voici le resultat des commandes que vous avez demandez:

SQL> startup
ORACLE instance started.

Total System Global Area 480735176 bytes
Fixed Size 737224 bytes
Variable Size 150994944 bytes
Database Buffers 327680000 bytes
Redo Buffers 1323008 bytes
Database mounted.
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/oradata/ICTPRD/system/system001.dbf'



SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01100: database already mounted


SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/oradata/ICTPRD/system/system001.dbf'

[LeoAnderson]

la prochaine fois, pensez aux balises [ code ] ou [ quote ] ! ;-)

Sinon, le message d'erreur indique que le fichier 1 (system) est plus "ancien" que le reste de la base (en tous cas, que les fichiers de contrôle).
Hors, vous disiez avoir restaurer les data ?
Ce fichier 1 est réservé à dictionnaire de la base Oracle et ne contient (normalement) pas de données utilisateur....

Il faudrait que vous consultiez la vue v$data_files (ou v$datafiles ou v$datafile, je sais plus mais je n'ai pas d'Oracle sous la main) afin d'identifier le n° du fichier que vous avezrestauré.
S'il s'avère que c'est effectivement le fichier 1 que vous avez restauré et que vous n'avez pas de sauvegardes complète de la base sous la main...
Au fait, la base est-elle en archive log ?

Code :

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

archive log list

De toutes façons, vous pouvez toujours tenter un

Code :

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

ALTER DATABASE RECOVER DATAFILE 1;

mais je suis plutôt pessimiste.

[novice_oracle]

on est pas en mode archivelog

Code :

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

1
2
3
4
5
6
7
8
 
SQL> archive log list
Database log mode              No Archive Mode
Automatic archival             Disabled
Archive destination            /u01/app/oracle/product/9.2.0/dbs/arch
Oldest online log sequence     267
Current log sequence           269
SQL>

es qu'il y a possibilité de regler le probleme sans recuperer les données?? (recuperer une base vierge)
peut-on regenerer les fichiers de controle?

[LeoAnderson]

Tant que vous ne nous aurez pas dit ce que vous avez exactement fait -nom et n° des fichiers, opérations réalisées, ... il nous sera impossible de vous répondre !

je ne vous cache cependant pas que le fait de ne pas être en mode archive log ne va pas aider !

[novice_oracle]

l'administrateur system a restaurer les fichiers de controle control01.ctl et control02.ctl, les fichiers .dbf et les fichiers redo corespondant à la meme date pour essayer de syncroniser le tout, mais malheureusement le meme probleme perciste. hier (avant d'effectuer cette restauration) c'etait l'erreur suivante qui s'affichée:
ORA-01110: data file 1: '/oradata/ICTPRD/index/stored_index001.dbf'

mais aprés la restauration c'est:
ORA-01110: data file 1: '/oradata/ICTPRD/system/system001.dbf'

maintenant on essaye de recuperer la base sans les données, comment le faire ??

[LeoAnderson]

Merci de penser aux balises [ code ] et [ quote ] ! (bis repetita)

Sinon, si vous faites 36 essais à la fois au petit bonheur la chance sans tenir compte des questions/suggestions que l'on vous propose, je ne vois pas bien en quoi on pourrait vous aider...

[novice_oracle]

désolé d'avoir oublié les balises, mais il faut me comprendre, dans la situation ou je suis, je risque d'oublier mon nom, car c'est la base production que je viens de perdre.

[LeoAnderson]

Je comprends, mais surtout, n'éditez pas votre message ni ne précisez quelles sont les opérations que vous avez faites(quels fichiers, quels n° de fichiers) ni dans quel ordre, ni les messages obtenus...

Ceci étant, une base de prod. sans sauvegardes ni archive log...

[LeoAnderson]

Par exemple, dans les messages d'erreurs que vous citez, c'est toujours le fichier n°1 mais il n'a pas le même nom...

Donc, si vous pouviez donner le n° des fichiers avec leurs noms, les opérations faites, quand, dans quel ordre, le message obtenu, ça serait pas mal ! ;-)

[bouyao]

Le problème vient des fichiers de contrôles

Essayer de créer les fichiers de contrôle voir l'article Fichiers de contrôle

Pour l'index, on peut les récréer manuellement.

Voir aussi l'article de
Sauvegarde

[LeoAnderson]

Je ne crois pas...
Dans son 1er message il dit

les fichiers de données .dbf on etaient ecrasés par des anciens

Et avant de faire tout et son contraire, il serait bon de déterminer précisément ce qui a été fait !

[gregory.broissard]

la base de prod en NoarchiveLog, vous cherchez les ennuis.

Bref, on va essayer de resynthétiser l'ensemble.

Ce qui se passe c'est que vous avez restauré des fichiers de données qui ne sont pas en phase avec les fichiers de contrôle. C'est à dire que les numéros de SCN dans les fichiers restaurés (par erreur) ne sont pas en phase avec les numéros de SCN référence dans les fichiers de contrôle.

Donc dans ce cas là, procéder comme suit :

Code :

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

1
2
3
4
 
Startup mount
alter database recover datafile 1 ;
alter database open;

A partir du recover datafile 1, vous avez 2 possibilités étant donné que vous n'etes pas en archive log:
1/ Un cycle complet de redo log n'a pas eu lieu et dans ce cas là, le recover se passera bien.
2/ Un cycle complet de redo log a eu lieu et dans ce cas là, n'étant pas en archive log, votre seule solution est de restaurer la base complète à la dernière sauvegarde valide que vous avez. Conséquence, vous perdez les données ajoutées entre la sauvegarde et maintenant. C'est le risque majeur du NoArchiveLog.

Donc ca c'était votre probleme de départ.

Ensuite, il s'est avéré que c'etait le TBS system que vous avez touché. Donc vous avez restauré les redologs, control files associés à ce fichier. Et vous avez constaté avec logique que maintenant c'était vos vrais fichiers de données qui étaient désynchronisés. Logique, leur numéro de SCN est plus avancé que celui mentionné dans le Control file.

Et donc là, on faut cette fois resynchroniser les fichiers de données (stored_index001.dbf).

Et c'est ce que vous avez fait en restaurant les fichiers et à nouveau c'est system qui n'est plus synchrone. Alors là par contre c'est pas normal.

Pour récupérer une base sans données (interet faible). Vous pouvez toujours dropper la base et la recréer...