Discussion :

[olivier]]

Bonjour.

J'ai une base ORACLE 10G 10.2.0.5.0 sous windows 2003 server sp2.
J'ai un fichier ORA qui est défectueux sur le disque. (message "...inconsistent data ..." dans le journal des évènement systèmes).

J'ai créé un tablespace pour récupérer les données de ce datafile. (je me suis basé sur dba_segments).
J'ai ensuite passé la commande

Code :

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

alter database datafile 'monfichier' offline drop;

J'ai arrêté la base (shutdown immediate), renommé le fichier et rouvert la base.
Lorsque j'interroge dba_data_files, mon fichier est toujours là mais ONLINE_STATUS = RECOVER .

Comment dois-je procéder pour que le fichier "n'existe plus" pour ORACLE?

Merci de votre aide

[Ikebukuro]

Voici ce que j'ai trouvé comme restrictions sur le site d'Oracle : est-ce que ton datafile est dans une de ces situations?

Restrictions for Dropping Datafiles

The following are restrictions for dropping datafiles and tempfiles:
The database must be open.

If a datafile is not empty, it cannot be dropped.

If you must remove a datafile that is not empty and that cannot be made empty by dropping schema objects, you must drop the tablespace that contains the datafile.

You cannot drop the first or only datafile in a tablespace.

This means that DROP DATAFILE cannot be used with a bigfile tablespace.

You cannot drop datafiles in a read-only tablespace.

You cannot drop datafiles in the SYSTEM tablespace.

If a datafile in a locally managed tablespace is offline, it cannot be dropped.

[olivier]]

Merci de te pencher sur le sujet.

J'avais trouvé ces restrictions.
Le tablespace du fichier est en "locally managed" mais OnLine.
j'ai fait la manip base ouverte (en mode restrict, mais ouverte)
Normalement, le datafile est vide puisque j'ai déplacé les objets présents dans ce datafile en me basant sur dba_objects.
Et ce n'est ni le tablespace SYSTEM ni un bigfile.

[pachot]

Bonjour,
Si le tablespace est vide, alors c'est le tablespace qu'il faut supprimer.
La syntaxe "alter database datafile 'monfichier' offline drop;" veut en réalité dire "mettre le datafile offline dans le but de dropper le tablespace"Cordialement,
Franck.

[olivier]]

Merci Pachot.

Fort de ta réponse, j'ai voulu supprimer le tablespace et j'ai compris mon erreur.
Comme je l'ai dit, pour déplacer les objets contenus dans mon datafile, je me suis basé sur dba_segments.
Or, quand j'ai voulu déplacer tous les fichiers de mon tablespace vers un autre tablespace, il s'est avéré que des objets étaient partiellement contenu dans le datafile que je voulais supprimer.

Pour être exhaustif dans le contenu du datafile, il fallait me baser sur dba_extents.
Là, on a la liste des objets présents, entièrement ou partiellement, dans le datafile (pour info, il faut faire le lien entre DBA_EXTENTS.RELATIVE_FNO et DBA_DATAFILES.FILE_ID).

J'ai donc restauré mon datafile

Code :

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

Recover datafile 'monfichier';

fini de déplacer le contenu de mon tablespace, et là j'ai pu simplement exécuter

Code :

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

 alter tablespace MonTablespace drop datafile 'monfichier';

merci de votre aide à tous les deux.

[pachot]

Pour être exhaustif dans le contenu du datafile, il fallait me baser sur dba_extents.

Oui, effectivement. DBA_SEGMENTS ne va montrer que le header du segment.

Là, on a la liste des objets présents, entièrement ou partiellement, dans le datafile (pour info, il faut faire le lien entre DBA_EXTENTS.RELATIVE_FNO et DBA_DATAFILES.FILE_ID).

La jointure doit se faire sur FILE_ID et non sur RELATIVE_FNO. Ils ont souvent la même valeur sauf quand on transporte des tablespaces ou qu'on a beaucoup de datafiles.

[olivier]]

Comme FILE_ID n'existait pas pas dans DBA_SEGMENTS, j'ai cru qu'il en était de même pour DBA_EXTENTS.
Merci pour ce complément.