Discussion :

[schlitters]

Bonjour,

Sur serveur LINUX RedHat Linux 4AS, et une base ORACLE 10R1, je m'amuse à faire quelques tests de crash de base ... en mode ARCHIVELOG

J'ai créé dans ma base une tablespace USERS qui contient 3 datafiles users01,users02,user03. Je précise que ce tablespace est vide (aucune table, vue etc ...)

Quand j'essaye de supprimer un datafile du tablespace par:

Code :

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

alter database datafile 'users03.dbf' offline drop;

le status du datafile passe en RECOVER

Code :

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

select name, status from v$datafile;

Le fichier est toujours présent physiquement sur le disque, et logiquement dans la base. Même si le fichier n'est pas effacé du disque, je pensais au moins qu'il était supprimé de la base ?

Quand j'essaye de repasser le datafile en mode online:

Code :

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

alter database datafile 'users03.dbf'  online;

oracle me renvoie cette erreur:

Code :

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

1
2
ORA-01113: le fichier 6 nécessite une récupération aprés défaillance matérielle
ORA-01110: fichier de données 6 : 'users03.dbf'

Pourquoi puisque cette suppression de datafile est normal (je veux dire faite par une ligne de commande) ORACLE considére-t-il qu'il s'agit d'une perte de fichier (style fichier effacer physiquement) ?

J'ajoute que je test la suppression d'un datafile, parce que j'ai été confronté à un probléme quasi similaire sur une base de prod.

Le datafile avait été effacé physiquement, j'ai réussi (je ne sais pas comment ) à le mettre offline dans la base, puis en voulant le supprimer de la base je me suis retrouver avec un status RECOVER dont je n'arrivais plus à me débarrasser.

Comment dire à ORACLE que ce datafile n'existe plus, et qu'il faut qu'il le supprime de son doctionnaire ?

Je parcours depuis 2 jours les tuto d'oracle sur le site ... mais là je sêche !!

D'avance merci pour vos explications

Fred

[Jaouad]

Bonjour Fred ,
Ici tu dit à Oracle met moi ce datafile offline car je vais le supprimer.Voila pourquoi il est en status recover et non pas disparu complétement du dictionnaire de données.

Je rappel que la commande :

Code :

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

alter database datafile 'users03.dbf' offline drop;

ne permet pas de supprimer un datafile de la base de données mais uniquement dit à Oracle de mettre ce fichier offline en vue d'une suppression ultérieure. Seul la commande drop tablespace va pouvoir supprimer un tablespace.

Lorsque tu souhaites le remettre en ligne par le biais du online , cela est impossible parce que le SCN systém a changer. d'ailleurs le simple fait de modifier l'état de ton datafile à réussi à changer le SCM Global et de facto devient différents de celui qui est contenu dans le header du datafiles.

Afin de pouvoir récuperer ton datafile , il suffit qu' Oracle mette à jour le SCN du fichier grace à la commande :

Code :

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

recover database

Voila j'éspére que cela t'aura aidé

[orafrance]

c'est impossible de supprimer un datafile. Pour se faire il faut recréer le tablespace

Il faut faire un RECOVER simplement parce que le SCN du datafile ne bouge plus (j'imagine ) quand il est droppé contrairement au SCN courant. Donc quand tu le remets OFFLINE il faut réaligner les SCN.

[orafrance]

post simultané... ça va on a dit la même chose

[Jaouad]

post simultané... ça va on a dit la même chose

Pourquoi tu avais un doute

une doc qui devrait être pas mal : Les différents scénarios pour pouvoir restaurer un datafile

C'est une doc Métalink

[schlitters]

Ok, merci pour ces précisions

Il semble que ce soit une confusion de ma part. Certainement à cause du drop à la fin.

Pour supprimer un datafile du dictionnaire de données, on obligé:

• soit de supprimer le tablespace auquel il appartient, et par conséquent tous les datafiles du tablespace.
• soit de créer un tablespace dans lequel on va déplacer le datafile à supprimer, puis de supprimer le tablespace. (je ne sais pas si c'est possible d'ailleurs)

Comment faire si on a créé un datafile dans le mauvais tablespace, et que ma deuxiéme solution (ci dessus) ne fonctionne pas ?

Fred

PS: Merci pour la doc je vais potasser ça ....

[Jaouad]

tu as la réponse dans ton post :

- On recrée un TBS , on déplace les objets , on droppe le TBS , on le recrée puis on va redéplacer les obejts. Ca c'est si tu tiens à ce que tes objets soit le TBS précis . Sinon tu recré les TBS et tu déplace puis tu supprime simplement l'ancien TBS

[schlitters]

Je viens de faire un test de déplacement de datafile. Il semblerait que la encore il y ai une confusion de ma part.

Dans mon tablespace USERS, j'ai trois datafiles (users01.dbf,users02.dbf,users03.dbf). Je pars du principe que users03 a été créé inutilement et qu'il faut que je le supprime du tablespace. Pour le supprimer je n'ai pas d'autre choix que de supprimer le tablespace. Je fais donc:

Code :

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

drop tablespace USERS;

Maintenant il faut recréer le tablespace USERS avec seulement les deux datafiles (users01.dbf et users02.dbf)
Comme les deux datafiles existent déjà je ne peux pas faire:

Code :

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

1
2
create tablespace USERS datafile 'users01.dbf' size 5M;
alter tablespace USERS add datafile 'users02.dbf' size 5M;

Je fais :

Code :

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

1
2
create tablespace USERS datafile 'a_effacer01.dbf' size 5M;
alter tablespace USERS add datafile 'a_effacer02.dbf' size 5M;

pour pouvoir recréer le tablespace USERS
puis:

Code :

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

1
2
alter database rename file 'a_effacer01.dbf' to 'users01.dbf';
alter database rename file 'a_effacer02.dbf' to 'users02.dbf';

pour pouvoir récupérer mes datafiles dans le bon tablespace.

Le probléme c'est que quand je veux remettre le tablespace USERS dans le status online

Code :

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

alter tablespace USERS online;

ORACLE me renvoie une erreur:

Code :

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

1
2
3
ORA-01122: échec de contrôle de vérification pour le fichier BdD 4
ORA-01110: fichier de données 4 : 'users01.dbf'
ORA-01203: incarnation erronée de ce fichier - création SCN erronée

J'en conclus donc qu'on ne peut pas déplacer de datafile de cette façon, voir même ne pas déplacer de datafile d'un tablespace à un autre.
On est donc obligatoirement obligé de déplacer les objets du tablespace ?
Ce qui me semble quand même assez lourd à faire si il y a plus d'une centaine d'objets à déplacer.

Mon raisonnement est il correct, ou est ce que je suis totalement à coté de la plaque et qu'il vaut mieux que je laisse tomber ORACLE ?

[orafrance]

Pourquoi tu avais un doute

j'ai toujours un doute... je ne suis malheureusement pas le gourou que sont certains d'entre vous

[Jaouad]

Mon raisonnement est il correct, ou est ce que je suis totalement à coté de la plaque et qu'il vaut mieux que je laisse tomber ORACLE ?

Ton raisonnement n'est pas bon , tu confond quelques notions dans ta procédure.
La procédure de renommage des fichiers ne fait pas changer de tbs pour un fichier mais permet uniquement soit de renommer le fichier soit de le déplacer. Mais il est toujours rattacher au même TBS.

Si tu as un TBS tablespace_1 avec trois datafiles fic1, fic2 et fic3 . Tu souhaites supprimer fic3.

- 1) tu crée un TBS temporaire ou tu va stocké provisoirement tes données tbs_temp.

- 2) tu déplaces tes tables dans le tbs temporaire, sauf pour les index ou il est plus rapide de les supprimer.

- 3) tu recrée le tbs tablespace_1 avec les deux fichiers :fic1 et fic2 et tu refait le chemin inverse pour les tables sauf pour les index ou tu vas les reconstruire ( Pense à utiliser sys.dbms_metadata.get_ddl avant la supprésion des index)

- 4) tu droppe le tbs temporaire en pensant à including content. Tu supprimes par une commande OS les fichiers. Tu repasses les stats sur les index et les tables . SI la procédure concerne une table il vaut mieux penser à reconstruire les index. ( avec toutes les clauses parrallel , nosort , nologging ... )

Voila ce n'est qu'une procédure sommaire, il convient de la developper.

deux petites remarques. Ce n'est pas une opération banale, donc si c'est une production la base doit être fermé

Lorsque tu mets offline , un datafile il ne faut pas oublier qu'il y a toujours une référence dans le tbs system ( dictionnaire des données )


Voila j'éspere que cela eclaircie un peu ta lanterne

j'ai toujours un doute... je ne suis malheureusement pas le gourou que sont certains d'entre vous

en plus il est modeste ,mais il a tout pour plaire ...

[schlitters]

Voila j'éspere que cela eclaircie un peu ta lanterne

Oui je te remercie, maintenant tout est limpide (même si je ne devrais peut être pas dire ça )

Je crois qu'en fait je me suis posé trop de questions dés le départ , et surtout je ne voulais pas croire que l'on était obligé de déplacer tous les objets d'un tablespace. Je trouve ça assez fastidieux si il y a moult objets à deplacer

Merci encore pour tes explications

Fred