Suppression de fichier dbf par mégarde

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 :fleche: /oracle/oradata/MADB/INT1_DATA.dbf
  2. tablespace INT1_INDEXES :fleche: /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 :fleche: /oracle/oradata/MADB/INT2_DATA.dbf
  2. tablespace INT2_INDEXES :fleche: /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

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

Code:

---

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:

---

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:

---

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:

---

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é :oops:

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

merci

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

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

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:

   ---

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

Citation:

---

Envoyé par Marc Musette

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

---

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

Citation:

---

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

   ---

   *._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 :cry:

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é

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

faut que je rajoute au fichier :

Code:

---

*._allow_resetlogs_corruption=true

---

ou

Code:

---

_allow_resetlogs_corruption=true

---

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

Code:

---

ALTER DATABASE open resetlogs;

---

parce qu'il me jette une erreur

Code:

---

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

---

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

Pour les commandes à passer

Code:

---

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

merci de ton aide ojo77 !

Malheureusement l'erreur est toujours présente :(

Bonjour,

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

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:

---

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.

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:

---

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

---

Merci
PoichOU

Citation:

---

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:

---

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:

---

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

---

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:

---

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.

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.

Merci beaucoup Franck !

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

Un GRAND GRAND merci à vous :ccool:

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.

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/