Version imprimable
Bonjour à tous,
J'ai un UNDO tablespace qui a atteint les 6 gigas.
Comment faire pour en vider le contenu afin de libérer de la place sur le serveur ?
Je pensais (à tord visiblement) qu'en arrêtant et redémarrant la base cela se ferait tout seul ....
Merci à vous de me répondre[/b]
il faut le recréer :/ (créer un nouveau, changer le paramétre undo_tablespace, redémarrer la base et droper le gros undo)
Mais réduire la taille du UNDO ne t'aidera probablement pas de toute façon, si il a atteint cette taille c'est que celle-ci est nécessaire et il l'atteindra donc à nouveau :?
Je suis d'accord avec Orafrance sur le principe mais je ne crois pas qu'il soit nécessaire de rédémarrer la base.
Cf. http://asktom.oracle.com/pls/ask/f?p...16201745120691
Laly.
exact sauf que les manipulations sur le UNDO sont assez... sensibles ;)
http://www.developpez.net/forums/viewtopic.php?t=274005 ;)
OK merci pour la précision Orafrance.
Laly.
Pour info, il existe un bug sur le tablespace undo à partir de la version 9.2.0.2. Bug n°2660394 corrigé avec la version 9.2.0.5 voir note dans metalink n°271119.1
pour ceux qui n'aurait pas acces à Metalink:
Citation:
The information in this article applies to:
Oracle Server - Enterprise Edition - Version: 9.2.0.2
This problem can occur on any platform.
Symptoms
Undo tablespace continues to increase in size.
Cause
+ The undo tablespace has Autoextend On specified.
+ The Logic used by AUM is :
1) A new extent will be allocated from the undo tablespace.
2) If failed, try stealing an expired extent from another undo segment. This
involves shrinking from the other segment and adding to the current undo
segment.
3) If failed, try reuse an unexpired extent from the current undo segment.
4) If failed, try stealing an unexpired extent from another undo segment.
5) If all failed, report an "Out-Of-Space" error.
+ Current AUM segment extend algorithm will grow the segment before trying to
reuse expired extents of other segments. If it is an extensible undo tablespace,
the tablespace may continue to grow.
+ Though Ideally it should, perform auto extension of the undo tablespace only
after the stealing of expired extents but before stealing unexpired extents.
+ This problem is documented in Bug 2660394 which is fixed in 9.2.0.5
Fix
+ Use the following query to find if EXPIRED EXTENTS of other segments are used or not:
select sum(EXPSTEALCNT), sum(EXPBLKRELCNT), sum(EXPBLKREUCNT) from v$undostat;
A output of '0' for sum(EXPBLKREUCNT) confirms that expired extents of other segments are not used
+ Use following query to find out the HWM of all the undo segments:
select n.name,extents,rssize/(1024*1024) rssize_MB,
hwmsize/(1024*1024) hwmsize_MB
from v$rollstat s,v$rollname n
where s.usn = n.usn
/
+ You have 2 options to workaround / solve this problem:
1st ---> To workaround it
- Stop the autoextend on the tablespace
2nd ---> Apply the patchset 9.2.0.5.0 for a permanent solution.
Voici la bonne nouvelle :
J'ai réussi à vider mon undo tablespace en lançant le script suivant, qui fonctionne très bien (je l'ai fait sur 3 serveurs différents et le résultat est OK) :
Pour info, il n'est pas necessaire de faire un stop et start de la base, tout du moins si on execute scupuleusement les lignes de commandes que j'indique.Code:
2
3
4
5
6
Encore merci de votre aide ....
salut, je suis tombé sur ce post par une recherche google, et cela a résolu mon problème.
Je me permets d'ajouter un truc, certes relevant ridiculement du détail, mais si vous avez ouvert OEM et ouvert la fenêtre du UNDOTBS01, celle où on peut changer autoextend, et bien la requête ne supprime que le tablespace pas le datafile (probablement dû au lock du fichier)
Donc le reste de la requête plante, il faut débloquer le fichier et le supprimer à la main puis lancer le reste du cmd.
a+
Bonjour,
la permutation du script avec ALTER system pour changer l'undo_tablespace :
puis revenir à l'ancien nom de fichierCode:
2
je ne vois pas ce que ca apporte ?Code:
2
est ce vraiement important de revenir au nom de fichier original ??
merci d'avance