Discussion :

[ducho]

Bonjour

Oracle 10.2

Ce tablespace d' un infocentre, a doublé apres une mise à jour
de l'infocentre de 2G° à 4G° .

L'espace occupé dans le tablespace undo n'est pas libéré même apres un redémarrage de la base .

c'est surement normal mais je n'ai pas trouvé d'infos dans la doc
qui expliquent ce comportement.

Actuellement pas de connexion, pas de transaction sur la base
l'espace n'est donc pas utilisé , je pensais qu'apres un redémarrage
de la base , l'occupation de ce tbs redescendrait à 10% environ .

son comportement ressemble au tablespace temporaire
(quand à lui, c'est expliqué dans la doc !!)

Si vous avez une explication ...

cordialement

[Pomalaix]

Vous êtes en UNDO_MANAGEMENT=AUTO je suppose ?

Oracle ajuste le nombre et la taille des segments d'annulation automatiquement selon la charge, mais ce n'est pas instantané, et en tout cas ça ne va pas réduire la taille du tablespace d'annulation.

A titre d'information, vous pouvez regarder le nombre et la taille actuelle des segments d'annulation :

Code :

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

1
2
3
select owner, segment_name, tablespace_name, bytes/1024/1024 taille_Mo 
from dba_segments 
where segment_type in ('ROLLBACK', 'TYPE2 UNDO');

Si la taille actuelle des fichiers UNDO vous pose problème, il reste possible de tenter un RESIZE, ou bien de créer un nouveau tablespace d'annulation, de l'activer (c'est lui que vous indiquez désormais dans le paramètre UNDO_TABLESPACE) et de supprimer l'ancien une fois qu'aucune transaction ne le référencera.

Néanmoins, si le tablespace UNDO a atteint une certaine taille, c'est peut être que c'était justifié, et que ça recommencera.

[ducho]

merci pomalaix,

Oracle ajuste le nombre et la taille des segments d'annulation automatiquement selon la charge, mais ce n'est pas instantané, et en tout cas ça ne va pas réduire la taille du tablespace d'annulation.

effectivement :
maintenant il n'est plus occupé qu' à 40% .



j'imagine que dans deux heures il ne le sera plus qu'à 10% .
entretemps, il y a eu une activité sur la base, oracle doit gérer
son propre espace au moment ou il en a besoin
(le segment utilisé par la transaction vu dans dba_undo_extents
faisait 3 G°) .

mon souci n' était pas la taille du tbs mais son taux d'occupation .

je vais laisser oracle gérer ça

cdlt