Drop undo tablespace

**laurentschneider** · 30/01/2007, 14h59

tu peux tenter un RECOVER UNTIL TIME AVANTTONDROP

**Pomalaix** · 30/01/2007, 15h02

Envoyé par nikeou

Non le fichier physique UNDOTBS01.dbf existe toujours.
...
Puis-je encore agir avec ce datafile ?

Ah, bonne nouvelle ça !!

Donc déjà il faut remettre le fichier ONLINE, s'il veut bien.

Ensuite pour chaque segment UNDO relatif à ce fichier, faire l'opération suivante :

Code :

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

1
2
alter system dump undo header _SYSSMU1$;
alter system dump undo header _SYSSMU2$;

Ca va vous générer (pour chaque segment) un fichier de trace sous le répertoire désigne par USER_DUMP_DEST.

Dans chacun de ces fichiers, recherchez la section TRN TBL, et examinez la colonne STATE. Si vous trouvez systématiquement 9 dans cette colonne, ça veut dire que toutes les transactions étaient terminées. Et dans ce cas vous pourrez réellement supprimer l'ancien tablespace UNDO et son fichier sous-jacent sans risque.

Code :

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

1
2
3
4
5
6
TRN TBL::
 
  index  state cflags  wrap#    uel         scn            dba            parent-xid    nub     stmt_num
  ------------------------------------------------------------------------------------------------
   0x00    9    0x00  0x018d  0x0020  0x0000.124f9720  0x00804226  0x0000.000.00000000  0x00000001   0x00000000
   0x01    9    0x00  0x018e  0x0007  0x0000.124f98f2  0x00804227  0x0000.000.00000000  0x00000001   0x00000000

Si vous trouvez une autre valeur que 9, à ma connaissance c'est mort, et vous devrez recréer la base.

**nikeou** · 30/01/2007, 15h27

Le fichier est de de nouveau ONLINE. ça c'est bon.

En revanche je n'arrive pas à lancer mes opérations sur les segments de rollback :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SQL> ALTER system dump undo header _SYSSMU1$;
ALTER system dump undo header _SYSSMU1$
                              *
ERREUR Ó la ligne 1 :
ORA-00911: CaractÞre non valide
 
SQL> ALTER system dump undo header '_SYSSMU1$';
ALTER system dump undo header '_SYSSMU1$'
*
ERREUR Ó la ligne 1 :
ORA-01534: le rollback segment '_SYSSMU1$' n'existe pas

Quelle doit-être la bonne syntaxe ?

**pifor** · 30/01/2007, 15h39

Essayez avec "..."

**Pomalaix** · 30/01/2007, 16h06

Il faut entourer les noms de segment UNDO par des apostrophes :

Code :

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

ALTER system dump undo header '_SYSSMU1$';

Vous ne retrouvez plus _SYSSMU1$ dans DBA_ROLLBACK_SEGS ?

**nikeou** · 30/01/2007, 16h56

Bon, restons calme.

Effectivement avec guillemets ou apostrophes j'ai le message qui me dit que le rollback segment '_SYSSMU1$' n'existe pas.
Alors j'essaie donc de vérifier dans la table DBA_ROLLBACK_SEGS.
Pour consulter la table DBA_ROLLBACK_SEGS il faut que la base soit ouverte.

Je l'ouvre donc :

Code :

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

1
2
3
4
5
6
7
SQL> alter database open;
alter database open
*
ERREUR Ó la ligne 1 :
ORA-01190: le fichier de contôle ou le fichier de données 2 est antérieur au
dernier RESETLOGS
ORA-01110: fichier de données 2 : 'D:\ORACLE\ORADATA\SIGEDM92\UNDOTBS01.DBF'

Revoilà mon UNDOTBS01.DBF qui se pointe...

Je suis complètement bloqué. Merci encore pour votre aide.

**nikeou** · 30/01/2007, 16h59

En fait, je suis à peu près sûr que de toute façon toutes mes transactions étaient terminées avant le plantage de ma base puisque cela a eu lieu après les heures de fermeture de l'entreprise avec aucune activité sur le serveur ORACLE.

N'est-il pas possible de droper le UNDOTBS01.DBF et de redémarrer sur un nouveau UNDOTBS comme j'essayais de le faire au début de cette discussion.

**laurentschneider** · 30/01/2007, 17h08

Envoyé par nikeou

N'est-il pas possible de droper le UNDOTBS01.DBF et de redémarrer sur un nouveau UNDOTBS comme j'essayais de le faire au début de cette discussion.

la bonne procédure aurait été de

changer la valeur de undo_tablespace
redémarrer la base
drop la tablespace undotbs1 y compris les fichiers

de faire un SHUTDOWN ABORT + OFFLINE DROP, c'est tout sauf propre

Maintenant il faut réparer ton erreur. Quand tu dis "j'ai un dump", tu veux bien dire "j'ai pas de vraie stratégie de backup, je fais seulement un export"... non?

Difficile pour moi de t'aider sans risquer de t'enfoncer encore plus dans les problèmes

**Pomalaix** · 30/01/2007, 17h13

Envoyé par nikeou

N'est-il pas possible de droper le UNDOTBS01.DBF et de redémarrer sur un nouveau UNDOTBS comme j'essayais de le faire au début de cette discussion.

Si, c'est possible, et je peux vous donner la manip.
Mais si par malchance, vos anciens segments UNDO sont référencés par des transactions non terminées, vous n'échapperez pas à la recréation de la base.

C'est pourquoi je vous ai proposé préalablement une procédure de vérification.

**nikeou** · 30/01/2007, 17h21

Oui effectivement je dois réparer proprement mon erreur...

Je ne dispose que d'un export, c'est bien ça, car la base est en place depuis peu et il est vrai que malgré mes appels du pied aucune vraie stratégie de backup n'a été mise en place avec notre service informatique.

Bref mea culpa. Je vous remercie infiniement pour votre aide. Il ne me reste, demain, qu'à remonter une nouvelle base dans laquelle j'importerai mes données issues du DUMP.

Merci à bientôt.

**nikeou** · 30/01/2007, 17h22

Aaaah d'accord Pomalaix, je suis preneur puisque de toute façon il ne me reste pas d'autres choix apparemment.

Merci d'avance.

**orafrance** · 30/01/2007, 17h29

Voici la procédure expérimentée à l'instant sur une base avec le même incident (on peut dire que tu es verni)

modifie le init.ora pour commenter toutes les lignes relatives au undo.
tu ajoutes le paramètre _corrupted_rollback_segments en listant les segments _SYSSMUxx$ http://www.developpez.net/forums/sho...d.php?t=235296
tu montes la base avec ce pfile (startup mount pfile=...)
tu droppes les datafiles du UNDO (alter database datafile 'D:\ORACLE\ORADATA\SIGEDM92\UNDOTBS01.DBF' offline drop)
tu ouvres la base (alter database open)
tu dropes le UNDO et tu le recrées.

Il n'y a plus qu'à redémarrer la base sur le pfile original

**Pomalaix** · 30/01/2007, 17h30

Ce n'est pas encore perdu à 100% hein !

Vous pouvez remettre le fichier OFFLINE, et essayer de redémarrer la base en ignorant les anciens segments UNDO.
Pour cela, ajoutez le paramètre suivant dans votre init.ora :

Code :

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

_offline_rollback_segments= _SYSSMU1$, _SYSSMU2$, _SYSSMU3$, _SYSSMU4$, _SYSSMU5$, _SYSSMU6$, _SYSSMU7$, _SYSSMU8$, _SYSSMU9$, _SYSSMU10$

Si ça marche, on passera à l'étape suivante.

**orafrance** · 30/01/2007, 17h30

Envoyé par Pomalaix

Mais si par malchance, vos anciens segments UNDO sont référencés par des transactions non terminées, vous n'échapperez pas à la recréation de la base.

en effet

**nikeou** · 30/01/2007, 17h47

Merci pour toutes ces infos, j'essaie ça demain à la première heure et vous tiendrez informés de la suite des évènements.

Bonne soirée.

**nikeou** · 31/01/2007, 05h58

Bon décidément ça ne commence pas très bien.

Je monte ma base puis je lance l'ordre de droper le UNDOTBS01.dbf et là :

Code :

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

1
2
3
4
5
6
SQL> alter database datafile 'd:\oracle\oradata\sigedm92\undotbs01.dbf' offline
drop;
alter database datafile 'd:\oracle\oradata\sigedm92\undotbs01.dbf' offline drop
*
ERREUR Ó la ligne 1 :
ORA-03113: fin de fichier sur canal de communication

J'essaie de redémarrer ma base pour voir si c'est mieux, mais impossible sans l'option abort :

Code :

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

1
2
3
SQL> shutdown normal
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

Je demande si un reboot du serveur ne lui ferait pas le plus grand bien. Malheureusement le serveur n'est pas dédié ORACLE et cette manip ne sera envisageable que ce soir.

A moins que vous ayez une autre idée ?...

**orafrance** · 31/01/2007, 09h08

quelle erreur y a-t-il dans l'alert.log ?

**nikeou** · 31/01/2007, 14h06

Bon. Désolé de ne pas vous avoir répondu plus tôt. Suite au rédémérrage du serveur, nombreux problème d'OS et de HD sont apparus...

Décision a été rapidement prise de remonter la base sur un autre serveur.

Suivi d'un import de l'ensemble des données issues d'un dump d'avant crash.

Recompilation des procédures, reconstructions des index, vérification des éléments invalides... et la base renaît enfin de ses cendres sans perte.

Laborieuse situation qui m'a pleinement fait réaliser l'importance d'une politique de backup digne de ce nom et nous allors sérieusement nous y pencher.

Merci pour toutes vos informations. Vos précieux conseils pour la récupération de la base avec un UNDOTBS corrompu me serviront peut-être un jour et je garde ça préciseusement dans un coin.

Désolé de vous avoir fait perdre un peu de temps et merci encore infiniement aux rédacteurs.

Bonne continuation à tous.

Drop undo tablespace

Administration Oracle

Discussions similaires

Partager

Partager