Espace TEMP rempli

**wissem.ba** · 04/04/2011, 11h54

Bonjour à tous,

J'ai un job qui se lance chaque Dimanche à 14h pour remplir une base à partir d'une autre base. En regardant le log ce matin j'ai découvert que l'import s'est arrêté à un certain moment avec ce message d'erreur :

ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

J'en ai parlé à mon DBA qui a bien voulu augmenté la taille du TEMP.

Sauf que je me pose pleins de questions :

Ma base fait 3.6 Go
La taille ancienne était à 5 Go et suite à l'intervention du DBA elle est à 6 Go

Comment se fait-il que la base a une taille de 3.6Go et qu'elle ait besoin de plus de 5Go comme espace TEMP?

Je voulais savoir également s'il y a moyen de suivre l'espace consommé par TEMP ?

Sur ce lien : http://www.ora00600.com/scripts/data...ring/temp.html

J'ai trouvé cette requête que j'ai essayée

Code :

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

1
2
3
4
5
SELECT ROUND(SUM( u.blocks * blk.block_size)/1024/1024,0)
FROM v$sort_usage u,
     (SELECT block_size
     FROM dba_tablespaces
     WHERE contents = 'TEMPORARY') blk;

Mais j'ai eu ce message d'erreur :

ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Error at Line: 4 Column: 10

Je comprends donc que je n'ai pas assez de droits de lancer cette requête, j'ai remplacé dba_tablespaces par user_tablespaces sachant que les deux tables en question possèdent les même colonnes comme le dit ce lien
http://download.oracle.com/docs/cd/B...htm#REFRN26287

Sauf que cela n'a pas fonctionné et j'ai eu ce message :

ORA-00942: table or view does not exist
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Error at Line: 2 Column: 5

Il n'y a aucun moyen de suivre l'évolution de TEMP sans passer par DBA ?

Merci pour vos réponses si vous avez rencontré le même problème.

**pifor** · 05/04/2011, 20h43

Avez-vous vérifié que vous avez accès à la vue V$SORT_USAGE ?
Essayer plutôt d'utilise V$TEMPSEG_USAGE qui peut donner des informations bien plus intéressantes comme le sql_id des requêtes.

Essayer de convaincre votre DBA de vous donner le rôle SELECT_CATALOG_ROLE.

Si votre base a besoin d'espace temporaire de plusieurs Go c'est probablement pour exécuter certains opérations couteuses comme des tris ou des jointures: pour éviter ceci essayez d'augmenter le paramètre d'instance PGA_AGGREGATE_TARGET pour utiliser la mémoire au lieu du disque (à condition bien sûr d'avoir la mémoire disponible). La vue V$PGA_TARGET_ADVICE donne des estimations pour ce paramètre.