Discussion :

[debdba]

Bonjour,
En oracle 9.2.0.5 sur AIX 5.3, nous avons une instance dont l'undo rétention est de 900 s., et systématiquement au moindre traitement il arrive à 99% de remplissage , on a beau agrandir l'espace disque, il réutilise la totalité.
Avez vous une explication qui me permettrait de comprendre pourquoi il ne "shrink" pas.

Merci

[orafrance]

est-ce qu'il est en autoextend ? Quel est la taille du INITIAL ? Comment vérifies tu le remplissage ? Est-ce que tu as des erreurs de UNDO trop petit ? Quelle est sa taille ?

[debdba]

Oui il est en autoextend, l'initial fait 65536k, le control d'espace se fait par une requete recoupant dba_free_space et dba_datafiles comme suit

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
select nvl(b.tablespace_name,                        
             nvl(a.tablespace_name,'UNKOWN')) name,  
       kbytes_alloc kbytes,                          
       kbytes_alloc-nvl(kbytes_free,0) used,         
       nvl(kbytes_free,0) free,                      
       ((kbytes_alloc-nvl(kbytes_free,0))/           
                          kbytes_alloc)*100 pct_used,
       nvl(largest,0) largest                        
from ( select sum(bytes)/1024 Kbytes_free,           
              max(bytes)/1024 largest,               
              tablespace_name                        
       from  sys.dba_free_space                      
       group by tablespace_name ) a,                 
     ( select sum(bytes)/1024 Kbytes_alloc,          
              tablespace_name                        
       from sys.dba_data_files                       
       group by tablespace_name )b                   
where a.tablespace_name (+) = b.tablespace_name      
order by 1 
/

Il n'y a pas d'erreur dans la log, mais il semble ne jamais libérer la place prise et grossit continuellement.
Pour info l'instance n'est jamais arrétée

[pifor]

Peut-être qu'il faudrait quand même spécifier une taille maximale pour le tablespace. Il y avait un bug à ce sujet en 9.2.0.4 mais corrigé en 9.2.0.5 (Bug 2660394 Auto extensible undo tablespace may grow before reusing expired extents).

Est-ce que vous avez des transactions dont la durée dépasse votre valeur de undo_retention soit 15 minutes ? Que donne la requête suivante qui calcule le nombre de blocs d'undo utilisé par toutes les transactions en cours d'exécution:

Code :

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

1
2
 
SELECT sum(used_ublk) from v$transaction;

[debdba]

Désolé, j'avais confondu le niveau de release avec ma base de recette, celle où j'ai le problème est bien en 9.2.0.4, ce qui correspond au bug référencé par Oracle.
Sinon la requette sur v$transaction = 10, je n'ai pas de transaction plus longue que le temps d'undo.

De savoir qu'il s'agit d'un problème connu, car je n'arrivais pas à comprendre pourquoi.
En attendant de migrer vers 9.2.0.5, existe t-il un moyen de forcer la libération des extents ?
Merci

[pifor]

Modifier le(s) datafile(s) de l'undo tablespace pour les mettre en AUTOEXTEND OFF devrait forcer Oracle à libérer les extents: http://download-uk.oracle.com/docs/c...files.htm#7426

[debdba]

Le tablespace UNDO est en autoextent depuis logtemps mais cela n'a rien changé.
Je cherche une commande qui force la libération des extents

[pifor]

Il faut mettre les datafiles en AUTOEXTEND OFF et non ON pour forcer Oracle à libérer les extents: dans la requête suivante, il faut que la colonne AUTOEXTENSIBLE soit à NO pour les datafiles de l'undo tablespace:

Code :

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

1
2
3
 
select file_name, tablespace_name, autoextensible 
from dba_data_files;

[debdba]

Merci de votre aide.
Je vais le repasser en autoextend OFF.
je pensais bien faire en le plaçant à ON, car je craignais le plantage.

Si je suis sur qu'il libère ses vieux extents plutôt que d'aller jusqu'au plantage par manque de place, je suis rassuré....