Discussion :

[PoichOU]

Bonjour,

j'ai supprimé des fichiers dbf par mégarde et Oracle n'aime pas ça

Petite explication : j'ai une base de données Oracle 10gR2 avec un user : INT1. Il a 2 tablespaces : 1 pour les datas et 1 pour les indexes (+1 temporaires bien sûr) :

• user INT1 :
  
  1. tablespace INT1_DATA /oracle/oradata/MADB/INT1_DATA.dbf
  2. tablespace INT1_INDEXES /oracle/oradata/MADB/INT1_INDEXES.dbf

J'ai voulu créer un 2ème user sur le même principe

• user INT2 :
  
  1. tablespace INT2_DATA /oracle/oradata/MADB/INT2_DATA.dbf
  2. tablespace INT2_INDEXES /oracle/oradata/MADB/INT2_INDEXES.dbf

J'ai donc crée le 2ème user puis j'ai fait une connerie : j'ai supprimé le fichier /oracle/oradata/MADB/INT2_INDEXES.dbf


Sur les "conseils" d'un collègue j'ai executé les commandes suivantes :

Code :

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

1
2
RECOVER DATABASE UNTIL CANCEL USING BACKUP CONTROLFILE;
RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;

Mais ça n'a rien changé

maintenant lorsque je démarre ma bdd, j'ai ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
 startup
ORACLE instance started.
 
Total System Global Area 2147483648 bytes
Fixed Size                  2022144 bytes
Variable Size             301991168 bytes
Database Buffers         1828716544 bytes
Redo Buffers               14753792 bytes
Database mounted.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

Si je veux me connecter il me dit que la base n'est pas "open" et si je veux ouvir la bdd j'ai ça :

Code :

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

1
2
3
4
5
6
SQL>  alter database open resetlogs;
 alter database open resetlogs
*
ERROR at line 1:
ORA-01194: file 1 needs more recovery to be consistent
ORA-01110: data file 1: '/oracle/oradata/MADB/system01.dbf'

J'ai également tenté :

Code :

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

1
2
3
4
5
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL;
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 29: '/oracle/oradata/MADB/INT2_INDEXES.dbf'
ORA-01157: cannot identify/lock data file 29 - see DBWR trace file
ORA-01110: data file 29: '/oracle/oradata/MADB/INT2_INDEXES.dbf'

ce fichier n'existe plus c'est celui que j'ai supprimé

Est-ce que quelqu'un voudrait bien m'aider ? J'ai plusieurs jours de boulot sur le user INT1

merci

Poichou

[PoichOU]

Petite précision, je n'ai pas réussi à restaurer les fichiers avec des outils UNIX.
Il me faut donc vraiment une solution oracle.

Est-ce possible

[Marc Musette]

Bonjour,
avez-vous un backup Oracle ? ou non ?

[ojo77]

La solution que j'appliquerais à votre place :

1. créer un fichier de paramétrage si vous utilisez un spfile create pfile from spfile.
2. Arrêter la base de données touch fichier_manquant
3. Sauvegarder la base de données à froid par copie des fichiers
4. Recréer le fichier manquant
5. Editer le fichier de paramètre pour y ajouter la ligne suivante
   

   Code :

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

   *._allow_resetlogs_corruption=true

6. redémarrer en mode mount et effectuer une recovery fictive (comme votre collègue vous l'a indiqué)
7. ouvrir la base alter database open resetlogs;
8. sauvegarder vos données par export datapump
9. détruire votre base de données
10. recréer votre base de données
11. importer les données par import datapump
12. recompiler les éventuels packages qui en ont besoin @?/rdbms/admin/utlrp
13. recréer vos index
14. supprimer le paramètre *._allow_resetlogs_corruption du fichier d'init

Ca devrait fonctionner si votre fichier perdu ne contenait que des index.

[PoichOU]

Bonjour,
avez-vous un backup Oracle ? ou non ?

Malheureusement non, du coup je suis dans l'obligation de refaire fonctionner mon oracle

La solution que j'appliquerais à votre place :

1. créer un fichier de paramétrage si vous utilisez un spfile create pfile from spfile.
2. Arrêter la base de données
3. Sauvegarder la base de données à froid par copie des fichiers
4. Editer le fichier de paramètre pour y ajouter la ligne suivante
   

   Code :

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

   *._allow_resetlogs_corruption=true

5. redémarrer en mode mount et effectuer une recovery fictive (comme votre collègue vous l'a indiqué)
6. ouvrir la base alter database open resetlogs;
7. sauvegarder vos données par export datapump
8. détruire votre base de données
9. recréer votre base de données
10. importer les données par import datapump
11. recompiler les éventuels packages qui en ont besoin @?/rdbms/admin/utlrp
12. recréer vos index
13. supprimer le paramètre *._allow_resetlogs_corruption du fichier d'init

Ca devrait fonctionner

J'ai fait create pfile from spfile et un shutdown immediate. Pour la sauvegarde des fichiers c'est ok également.
Par contre peux-tu me dire où je peux trouver le fichier de param à éditer ?


Merci à vous 2 de m'aider je suis vraiment en stress de ne pas récupérer mes infos

PoichOU

[PoichOU]

dans le répertoire /oracle/home/product/10.2.0/db_1/dbs
j'ai trouvé :

• initMADB.ora
• init.ora
• spfileMADB.ora

j'ai testé de rajouter *._allow_resetlogs_corruption=true dans le 1er fichier mais ça n'a rien changé

[ojo77]

Il faut renommer le fichier spfileMADB.ora en spfileMADB.ora.old
Editer le fichier $ORACLE_HOME/dbs/initMADB.ora pour ajouter la ligne concernant le paramètre _allow_resetlog_corruption.
Créer le fichier manquant touch fichier_manquantet effecteur le startup mount et la suite des opérations

[PoichOU]

faut que je rajoute au fichier :

Code :

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

*._allow_resetlogs_corruption=true

ou

Code :

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

_allow_resetlogs_corruption=true

une fois que c'est fait
je démarre avec startup mount puis je fais ?

Code :

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

ALTER DATABASE open resetlogs;

parce qu'il me jette une erreur

Code :

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

1
2
3
4
5
6
7
8
9
SQL> ALTER DATABASE open resetlogs;
ALTER DATABASE open resetlogs
*
ERROR at line 1:
ORA-01110: data file 29: '/oracle/oradata/MADB/INT2_INDEXES.dbf'
ORA-01115: IO error reading block from file 29 (block # 1)
ORA-27069: attempt to do I/O beyond the range of the file
Additional information: 1
Additional information: 1

[ojo77]

*._allow_resetlogs_corruption=true et _allow_resetlogs_corruption=true sont équivalents en monoinstance.

Pour les commandes à passer

Code :

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

1
2
3
4
5
startup mount
alter database recover database using backup controlfile until cancel ;
 
cancel
alter database open resetlogs;

Si l'erreur sur l'en-tête de fichier persiste, faites moi signe

[PoichOU]

merci de ton aide ojo77 !

Malheureusement l'erreur est toujours présente

[pachot]

Bonjour,

C'est quoi ces conseils ?
USING BACKUP CONTROLFILE;
open resetlogs
*._allow_resetlogs_corruption=true

Ne faites rien tant que vous ne comprenez pas pourquoi ! Surtout en n'ayant pas de backup !

Pour recréer un datafile quand on a pas de backup, c'est

Code :

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

alter database create datafile

Ensuite, si les transactions qui ont touché ce datafile sont encore dans les redo (ou archivelogs), le recovery devrait tout retrouver.

Cordialement,
Franck.

[PoichOU]

Bonjour Franck,

merci de t’intéresser à mon problème.

J'avoue ne pas comprendre toutes les commandes mais je suis dans une situation très compliquée alors il faut bien que je tente ma chance.

Si j'ai bien compris la solution proposée par ojo77, elle consiste à dire à Oracle de démarrer sans pour autant être très stable mais ce qui me laisserait le temps de récupérer mes infos sur mon user INT1. C'est pas forcément l'idéal mais ça me conviendrait grandement.

Ceci dit la solution que tu me proposes ma va aussi. La syntaxe est quelques choses du genre :

Code :

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

ALTER DATABASE CREATE DATAFILE '/oracle/oradata/MADB/INT2_INDEXES.dbf' AS 'INT2_INDEXES';

Merci
PoichOU

[pachot]

Si j'ai bien compris la solution proposée par ojo77, elle consiste à dire à Oracle de démarrer sans pour autant être très stable mais ce qui me laisserait le temps de récupérer mes infos sur mon user INT1.

Non, la solution qui t'a été proposée ne résoud pas le problème et va en rajouter d'autres...
Le premier conseil qu'il y avait à te donner, vu que tu n'as pas de backup et n'est pas en archivelogs, c'est de faire un backup: éteindre la base et faire un backup à froid. Parce que tu es dans une situation récupérable, et en cas d'erreur tu peux au moins revenir à cette situation.

Puis, calmement, faire le recovery nécessaire. Voici un exemple.

Je crée un tablespace et une table dedans:

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
18
19
20
21
22
23
24
25
$ sqlplus /nolog
 
SQL> connect ...
Connected.
SQL> create tablespace testdropdbf datafile '/tmp/test.dbf' size 5M autoextend off;
Tablespace created.
 
SQL> create table test (x char) tablespace testdropdbf;
Table created.
 
SQL> insert into test values('x');
1 row created.
 
SQL> commit;
Commit complete.
 
SQL> select * from test;
 
X
-
x
 
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

Je supprime le datafile:

Code :

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

$ rm /tmp/test.dbf

Je me reconnecte et tente de lire ma table (après flush buffer cache, sinon pas de lecture du fichier...):

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
18
19
20
21
22
23
24
25
26
$ sqlplus /nolog
 
SQL*Plus: Release 11.2.0.2.0 Production on Mon Mar 25 14:57:37 2013
 
Copyright (c) 1982, 2010, Oracle.  All rights reserved.
 
 
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
SQL> connect ...
Connected.
 
SQL> alter system flush buffer_cache;
System altered.
 
SQL> select * from test;
select * from test
              *
ERROR at line 1:
ORA-01116: error in opening database file 6
ORA-01110: data file 6: '/tmp/test.dbf'
ORA-27041: unable to open file
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

Maintenant, calmement, en espérant que toutes les transactions depuis la création se trouvent dans les redo logs (on ne peut pas espérer mieux sans backups ni archivelogs...):

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
SQL> alter database datafile '/tmp/test.dbf' offline drop;
Database altered.
SQL> alter database create datafile '/tmp/test.dbf';
Database altered.
SQL> recover datafile '/tmp/test.dbf';
Media recovery complete.
SQL> alter database datafile '/tmp/test.dbf'online;
Database altered.
 
 
SQL> select * from test;
 
X
-
x

Voilà, j'ai tout récupéré

Cordialement,
Franck.

[pachot]

Je viens de voir qu'il s'agit uniquement d'index dans le tablespace.
Donc au pire, il suffira de recréer le tablespace et rebuilder les index. Ca prend du temps, mais pas de perte.

Sinon pour la prochaine fois, voici un moyen de récupérer dans ce genre de cas, même sans avoir besoin des redo logs: http://niscodba.weebly.com/3/post/20...-still-up.html
Mais il ne faut pas éteindre la base pour faire celà.

Cordialement,
Franck.

[PoichOU]

Merci beaucoup Franck !

Ta solution a fonctionné et j'ai réussi à récupérer mes petits

Un GRAND GRAND merci à vous

[pachot]

Bravo,
Maintenant, n'oublie pas:
- de faire des backups. Ca arrive de faire une erreur (comme supprimer un fichier). C'est grâce aux backup qu'une erreur ne devient pas une catastrophe.
- de ne lancer n'importe quelle commande sans comprendre. Même en cas d'urgence.
Cordialement,
Franck.

[lallio]

Bonjour,

Ci-dessous un très bon article (en anglais) sur comment s'en sortir après un rm de datafiles sur une machine linux. Le tout avec une indispo très limité.

http://www.pythian.com/blog/how-to-r...h-no-downtime/