Restaurer un .dbf supprimé ? Possible ?

[bobinouze]

Bonjour à tous,

je me mets au bdd Oracle malgré moi de part mon job. Un de mes collègues à supprimer un .dbf important pensant économiser de l'espace disque .

Malheureusement, ce serveur, bien qu'il soit en prod, ne fait pas de backup du .dbf en question (pas de bol !)

Savez vous s'il existe une autre méthode pour récupérer ce fichier ? Peux-être en utilisant les fichiers de type redo-log ?
Pour info, le serveur est sous HP-UX.

Si jamais je ne peux pas le récupérer (Les données n'étant pas non plus hyper importantes), savez vous comment dois-je procéder pour m'en passer ?

La société de support que nous employons fait trainer les choses en longueur nous soutiens qu'il faut réinstaller ORACLE (1 semaine de travail) et j'aimerais beaucoup ne pas avoir à attendre qu'elle se réveille...

Merci d'avance pour vos nombreuses idées

[ojo77]

Je suppose que la base de donnée n'a pas été arrêtée dans l'interval.

Donc, si vous êtes en mode archivelog, vous devez pouvoir faire une sauvegarde RMan du tablespace et le restaurer (et donc retrouver votre fichier bdf).

En effet, le fichier peut être effacé mais encore présent sur disque parcequ'il est ouvert par la base de données.

Si vous n'êtes pas en mode archivelog, un export full est à envisager puis recréation de la base et import du dump.

Enfin il est possible de transférer l'ensemble des données du tablespace dans lequel il manque un fichier (appelons le T1) vers un autre tablespace de faire un alter database datafile offline drop de l'ensemble des fichiers constituant T1, puis de dropper T1 puis d'effacer l'ensemble des fichiers le constituant au niveau OS

Si le fichier est effectivement manquant (donc plus ouvert par Oracle), il faut voir les donnéesréupérable dans le tablespace, les sauvagarder et dropper le tablespace avec la méthode décrite au § du dessus.

En aucun cas, une réintallation d'Oracle n'est à envisager

[bobinouze]

Merci de votre réponse.

A priori, le mode archivelog n'est pas activé :

SQL> ARCHIVE LOG LIST
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 1830
Current log sequence 1832

Le fichier .dbf n'existe plus sur le disque à cause du rm.

Si je fais un SQL> SELECT tablespace_name,file_id,file_name FROM dba_data_files ORDER BY FILE_ID; le fichier dbf n'apparait pas dans la liste. Qu'es ce que cela indique ?

merci à tous !

[ojo77]

Le fichier est donc à priori perdu et non ouvert par Oracle.

Il faut donc sauvegarder les données du tablespace et effectuer les opérations de récupération du tablespace.

[boussafi]

as tu des sauvegardes de la base?

[bobinouze]

Bon, en réalité, je crois que cela va être plus compliqué que cela.

Le fichier dbf supprimé se nomme sysaux01_new.dbf.

Mon collègue l'a supprimé car ce fichier n'était pas récent et un similaire se nommant sysaux01.dbf est bien présent et mis à jour :

total 25635616
-rw-r----- 1 oracle dba 7553024 Sep 28 15:13 control01.ctl
-rw-r----- 1 oracle dba 7553024 Sep 28 15:13 control02.ctl
-rw-r----- 1 oracle dba 7553024 Sep 28 15:13 control03.ctl
-rw-r----- 1 oracle dba 52429824 Sep 28 04:52 redo01.log
-rw-r----- 1 oracle dba 52429824 Sep 28 15:12 redo02.log
-rw-r----- 1 oracle dba 52429824 Sep 27 22:58 redo03.log
-rw-r----- 1 oracle dba 9742327808 Sep 28 04:57 sysaux01.dbf
-rw-r----- 1 oracle dba 1992302592 Sep 28 15:12 system01.dbf
-rw-r----- 1 oracle dba 45096960 Nov 29 2010 temp01.dbf
-rw-r----- 1 oracle dba 94380032 Sep 27 00:48 temp02.dbf
-rw-r----- 1 oracle dba 1073750016 Sep 28 15:12 undotbs01.dbf
-rw-r----- 1 oracle dba 1056768 Sep 28 04:57 users01.dbf

Apparemment, ce fichier est très important mais je ne comprends pas pourquoi j'en ai 2 et ne vois pas trop comment est configuré oracle. Par contre j'ai bien un message d'erreur suite à l'éxécution de script utilisant la base oracle :

ORA-00376: file 10 cannot be read at this time
ORA-01110: data file 10: '/usr/ORACLE/[...]/sysaux01_new.dbf'
ORA-06512: at line 18]"

Je vais voir si je n'arrive pas à trouver une sauvegarde même si je n'y crois pas ...

[boussafi]

puisque sysaux01.dbf existe dans la liste des fichiers de données , je pense que le deuxieme (sysaux01_new)est un plus. il n'est celle de Oracle.
pour cela, pour eliminer le message d'erreur,tu procede comme suite:
si le fichier de données est dans un tablespace à part, tu peux dropper ce dernier.

Code :

ALTER TABLESPACE sysaux01_new DROP DATAFILE '/usr/ORACLE/[...]/sysaux01_new.dbf';

[agdid04]

Envoyé par boussafi

puisque sysaux01.dbf existe dans la liste des fichiers de données , je pense que le deuxieme (sysaux01_new)est un plus. il n'est celle de Oracle.
pour cela, pour eliminer le message d'erreur,tu procede comme suite:
si le fichier de données est dans un tablespace à part, tu peux dropper ce dernier.

Bonjour,

Je pense que le tablespace SYSAUX a été agrandi à un moment en y rajoutant un datafile ... et donc SYSAUX est composé de ces 2 fichiers.

A+

[boussafi]

oui, c'est un autre scenario.

[bobinouze]

Envoyé par agdid04

Bonjour,

Je pense que le tablespace SYSAUX a été agrandi à un moment en y rajoutant un datafile ... et donc SYSAUX est composé de ces 2 fichiers.

A+

Il est possible que ce deuxième sysaux soit rajouté puis non utilisé ?

Le plus récent étant le 1er. Le deuxième ne semblait pas avoir été modifié depuis plus d'un an...

[boussafi]

si c'est le cas tu peut eliminer le message d'erreur et mettre le tablespace en ligne

Code :

1
2
3
4
5
6
DELETE  FROM sys.file$ t
WHERE t.FILE# =(select  v.FILE# 
FROM  sys.v$dbfile v
WHERE name = '/usr/ORACLE/[...]/sysaux01_new.dbf';
commit;
ALTER tablespace SYSAUX online;