Drop undo tablespace

Version imprimable

Voir 40 message(s) de cette discussion en une page

30/01/2007, 12h01
nikeou

Drop undo tablespace

Bonjour,
Je suis désolé de réabordé un sujet qui semble l'avoir déjà été, mais pour lequel, en toute bonne foie, après moulte recherches dans le forum je n'ai pas trouvé de solution...

J'ai créé un nouveau 'UNDOTBS2' puis je l'ai déclaré comme mon nouveau tablespace UNDO

Code:

ALTER SYSTEM SET UNDO=UNDOTBS2

je cherche maintenant à supprimer l'ancien tablespace undo nommé 'UNDOTBS1' par un

Code:

DROP TABLESPACE UNDOTBS1;

Mais cette opération me renvoie l'erreur :

Code:

ORA-01548: rollback segment actif '_SYSSMU1$' trouvé ; arrêter suppression du tablespace

J'ai mis à jour mon fichier init.ora pour indiquer le nouveau nom pour UNDO puis j'ai redémarrer ma base...

Le DROP me retourne toujours le même message.

J'ai mis mon UNDOTBS1 en offline puis redémarré, toujours pareil...

Alors comment faire pour désactiver les segments de rollback qui m'empêche de supprimer mon tablespace devenu obsolète ?

Merci d'avance pour votre aide.
30/01/2007, 12h19
nikeou

Au fait, il s'agit d'une version 9i.

la procédure me semble correcte :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
SQL> show parameter undo_tablespace
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
undo_tablespace                      string      UNDOTBS1
SQL> create undo tablespace undotbs2 datafile '/space/prog/db/10.2/oradata/LSC01/undotbs02.dbf' size 50M autoextend on;
 
Tablespace created.
 
SQL> alter system set undo_tablespace='UNDOTBS2';
 
System altered.
 
SQL> drop tablespace UNDOTBS1;
 
Tablespace dropped.

essaye

Code:

1
2
3
4
5
6
7
select tablespace_name, owner, segment_name from dba_rollback_segs;
TABLESPACE_NAME                OWNER  SEGMENT_NAME
------------------------------ ------ ------------------------------
SYSTEM                         SYS    SYSTEM
UNDOTBS2                       PUBLIC _SYSSMU11$
UNDOTBS2                       PUBLIC _SYSSMU12$
...

pour comprendre ce qui se passe...

30/01/2007, 12h53
Pomalaix

Et dans l'alert.log, qu'est-ce que ça dit ?
Est-ce que vous trouvez quelque chose comme "SMON: mark undo segment 1 as needs recovery" ?
30/01/2007, 13h49
pifor

Essayez d'avoir la base en mode mono-utilisateur:

Citation:

startup restrict

et de ne pas faire de shutdown immediate/abort mais plutôt

Code:

shutdown normal;

Pour revenir au mode initial:

Code:

alter system disable restricted session;

Voici ce que j'obtiens :

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
27
28
29
30
SQL> SELECT tablespace_name, owner, segment_name FROM dba_rollback_segs;
 
TABLESPACE_NAME                OWNER  SEGMENT_NAME
------------------------------ ------ ------------------------------
SYSTEM                         SYS    SYSTEM
UNDOTBS1                       PUBLIC _SYSSMU1$
UNDOTBS1                       PUBLIC _SYSSMU2$
UNDOTBS1                       PUBLIC _SYSSMU3$
UNDOTBS1                       PUBLIC _SYSSMU4$
UNDOTBS1                       PUBLIC _SYSSMU5$
UNDOTBS1                       PUBLIC _SYSSMU6$
UNDOTBS1                       PUBLIC _SYSSMU7$
UNDOTBS1                       PUBLIC _SYSSMU8$
UNDOTBS1                       PUBLIC _SYSSMU9$
UNDOTBS1                       PUBLIC _SYSSMU10$
 
TABLESPACE_NAME                OWNER  SEGMENT_NAME
------------------------------ ------ ------------------------------
UNDOTBS02                      PUBLIC _SYSSMU11$
UNDOTBS02                      PUBLIC _SYSSMU12$
UNDOTBS02                      PUBLIC _SYSSMU13$
UNDOTBS02                      PUBLIC _SYSSMU14$
UNDOTBS02                      PUBLIC _SYSSMU15$
UNDOTBS02                      PUBLIC _SYSSMU16$
UNDOTBS02                      PUBLIC _SYSSMU17$
UNDOTBS02                      PUBLIC _SYSSMU18$
UNDOTBS02                      PUBLIC _SYSSMU19$
UNDOTBS02                      PUBLIC _SYSSMU20$
 
21 ligne(s) sÚlectionnÚe(s).

Donc toujours des références à UNDOTBS1... comment cela se fait-il ?

Je ne mets pas la main sur mon alert.log...

Si ça y est, et il est plein de :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SMON: about to recover undo segment 1
SMON: mark undo segment 1 as needs recovery
SMON: about to recover undo segment 2
SMON: mark undo segment 2 as needs recovery
SMON: about to recover undo segment 3
SMON: mark undo segment 3 as needs recovery
SMON: about to recover undo segment 4
SMON: mark undo segment 4 as needs recovery
SMON: about to recover undo segment 5
SMON: mark undo segment 5 as needs recovery
SMON: about to recover undo segment 6
SMON: mark undo segment 6 as needs recovery
SMON: about to recover undo segment 7
SMON: mark undo segment 7 as needs recovery
SMON: about to recover undo segment 8
SMON: mark undo segment 8 as needs recovery
SMON: about to recover undo segment 9
SMON: mark undo segment 9 as needs recovery
SMON: about to recover undo segment 10
SMON: mark undo segment 10 as needs recovery

Y a t-il un rapport ?

30/01/2007, 14h04
laurentschneider

essaye de redémarrer la base (shutdown immediate) encore une fois... tu n'es pas en RAC non?
30/01/2007, 14h15
nikeou

Excuse moi Laurent mais qu'entends tu pas RAC ?
30/01/2007, 14h19
pifor

RAC= Real Application Cluster= plusieurs instances pour la même base de données montée sur des systèmes de fichiers partagés.
30/01/2007, 14h23
Pomalaix
Citation:
Envoyé par nikeou

Si ça y est, et il est plein de :

Code:

1 2 3 4 5 SMON: about to recover undo segment 1 SMON: mark undo segment 1 as needs recovery ... SMON: about to recover undo segment 10 SMON: mark undo segment 10 as needs recovery

Y a t-il un rapport ?
Voui, un gros rapport même !!
J'imagine qu'il s'agit d'une base de prod bien sûr ?

Et avant de vous faire faire des manipulations hasardeuses, comment en êtes-vous arrivé là ? Pourquoi avez-vous eu besoin de définir un nouveau tablespace UNDO ?
30/01/2007, 14h25
nikeou

Non je suis dans en fonctionnement simple, un serveur, une instance, une base.
J'ai lancé un shutdown normal il y a 15mn et toujours rien, pas de réponse, alors que je pense que plus personne ne travaille sur la base à cette heure ci...

Que pensez-vous des :

SMON: about to recover undo segment 1
SMON: mark undo segment 1 as needs recovery

dans mon alert.log ?
30/01/2007, 14h33
pifor

D'après la note :

Citation:

Subject: SMON: ABOUT TO RECOVER UNDO SEGMENT %s messages in alert log
Doc ID: Note:266159.1 Type: PROBLEM
Last Revision Date: 17-AUG-2004 Status: PUBLISHED

il y a eu un problème à l'arrêt de la base qui nécessite recovery.

La note conseille d'exécuter la commande suivante:

Code:

alter rollback segment "XXX" online;

pour chaque rollback segment XXX référencé dans l'alert.log pour que Oracle puisse finir la recovery.

Ensuite arrêter/relancer sans shutdown abort devrait marcher.
30/01/2007, 14h34
nikeou

Oui il s'agit bien d'une base de Prod...

Ce matin, instance ORACLE muette. L'informatique m'informe que le réseau de l'entreprise qui a subi des pbs durant la nuit... Alors je décide de redémarrer l'instance :

>Shutdown abort

>startup mount

>recover

le processus de restauration déclare que mon fichier UNDOTBS1.dbf est corrompu, je demande la sauvegarde au service info : impossible, la sauvegarde de la nuit a foirée à cause des pbs de réseau...
J'ai donc essayé de recréer mon tablespace UNDO avec génération d'un nouveau DATAFILE.
La création de ce nouveau Tablespace n'a pas posé de pb.
J'ai dropé le DATAFILE corrompu mais donc impossible de droper le tablespace associé...

Voilà tout l'histoire.
30/01/2007, 14h41
laurentschneider
Code:

1 2 3 4 Shutdown abort startup mount recover
pourquoi?
30/01/2007, 14h43
laurentschneider

si tu as effacé ton datafile avant de dropper ton tablespace, c'est tout normal que ça plante.. en plus, avec UNDO, c'est grave. Dis-moi, il n'y aurait par hasard pas un backup qui traine si c'est une base de prod :mouarf:
30/01/2007, 14h47
nikeou

Lorsque mon instance plante et que je la stopppe par un 'shutdown abort' (c'est le seul mode d'arrêt possible dans ce cas) je lance toujours un recover au redémarrage.
Si le recover est inutile, ORACLE donne un message pour indiquer que c'est inutile, dans le cas contraire, et c'était le cas ce matin il délivre le message :
'Instance récupéré suite à défaillance matérielle'.

J'avoue ne pas avoir sans doute le niveau suffisant pour administrer correctement la base et je ne fais là que suivre les conseils que l'on a pu me transmettre...
30/01/2007, 14h50
Pomalaix

Citation:

Envoyé par nikeou

J'ai dropé le DATAFILE corrompu

Aïe, ça ne n'était vraiment pas la bonne idée !!!
Vraiment supprimé, ou mis de côté au cas où ?

La dernière fois qu'il m'est arrivé une mésaventure du même genre, le support Oracle m'a dit qu'il n'y avait qu'une chose à faire : faire un export de la base, puis la recréer entièrement.
30/01/2007, 14h52
nikeou

A vrai dire entre le moment où la base a du planter (cette nuit) et les dernières transactions, il s'est passé plusieurs heures, je ne pensais donc pas ce matin que le tablespace UNDO pouvait avoir de l'importance puisque je n'avais pas besoin de restaurer de données...

J'ai un DUMP complet de la base qui date d'hier fin d'après midi.

Crois-tu que j'ai intérêt à recréer une nouvelle base et restaurer mes données à partir du dump où y-a-t-il encore une chance de remettre en fonctionnement ma base actuelle ?
30/01/2007, 14h57
nikeou
Non le fichier physique UNDOTBS01.dbf existe toujours, je l'ai dropé avec cet ordre :
Code:

1 2 3 4 SQL> alter database datafile 'd:\oracle\oradata\SIGEDM92\undotbs01.dbf' offline drop; Base de donnÚes modifiÚe.
Puis-je encore agir avec ce datafile ?

Voir 40 message(s) de cette discussion en une page