Discussion :

[zidane2012]

bonjour
J'ai augmenté le tempfile de 5Go soit 10Go en total.
Lors d'un traitement ce tempfile a crashé après avoir atteint 7 Go !!!
No space left on device
Est-ce possible ?
Oracle voit t-il l'espace OS disponible lors de l'augmentation du tempfile ?
Comment j'ai pu augmenter le tempfile de 5 Go alors que j'avais à priori que 2Go de disponible ?
Please Help !

[jkofr]

L'allocation est effectuėe au moment ou des lignes sont insėrėes dans une table temporaire.
Donc ton comportement est normal...
Jko

[pachot]

Bonjour,
Les tempfiles sont crées en sparse files, l'espace n'est alloué que lorsqu'on écrit dedans.
Cordialement,
Franck.

[zidane2012]

Bonjour,
Les tempfiles sont crées en sparse files, l'espace n'est alloué que lorsqu'on écrit dedans.

Donc tu es d'accord avec moi qu'il faut se méfier de la taille max que pourrait atteindre un tempfile qui pourrait être bien inférieure à celle fixée par :

Code :

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

1
2
 
ALTER TABLESPACE TEMP ADD TEMPFILE '/app/data/tmp03.dbf' SIZE 5G REUSE;

Sinon une autre question :
Si dans une opération de tri , la PGA n'est pas suffisante pour faire le sort , est-ce que Oracle switche TOUTE l'opération de tri vers le temp où juste ce qui reste pour la finaliser ?
Enfin ,

Quelles sont les opérations les plus consommatrices en temp (tri , ...)?
Existe-t-il un Advisor pour ajuster la taille du temp ?
merci

[pachot]

Bonjour,

Donc tu es d'accord avec moi qu'il faut se méfier de la taille max que pourrait atteindre un tempfile qui pourrait être bien inférieure à celle fixée par :

Oui. Tout à fait d'accord.
C'est pour celà que je conseille soit de créer les tempfiles petits et en autoextend, soit de les mettre dans un filesystem spécifique.

Si dans une opération de tri , la PGA n'est pas suffisante pour faire le sort , est-ce que Oracle switche TOUTE l'opération de tri vers le temp où juste ce qui reste pour la finaliser ?

Tout sauf la partie qui loge en PGA. Par exemple, 100MB de workarea, 300MB à trier, il y aura probablement 200MB en tempfiles.

Mais si la taille des données est très très grande, le tri va se faire en plusieurs passes et on peut se retrouver à avoir plusieurs fois le volume total à mettre en tempfile.

Quelles sont les opérations les plus consommatrices en temp (tri , ...)?

Tris, group by, hash join, GTT,...

Existe-t-il un Advisor pour ajuster la taille du temp ?

dbms_xplan plan va montrer une estimation. Ça reste une estimation...

Cordialement,
Franck.

[zidane2012]

Quand une requête sollicite trop le tempfile quelle astuce permet de diminuer cette sollicitation coûteuse en I/O ?
Augmenter la PGA ? modifier un paramètre Oracle ? autre ?
merci

[FSiebert]

Quand une requête sollicite trop le tempfile quelle astuce permet de diminuer cette sollicitation coûteuse en I/O ?
Augmenter la PGA ? modifier un paramètre Oracle ? autre ?
merci

Vous pouvez utiliser le paramètre use_less_temp=true

Plus sérieusement, effectivement, agrandir la PGA peut permettre de diminuer l'utilisation du TEMP mais il serait plus judicieux de commencer par comprendre pourquoi la requête utilise beaucoup le TEMP et si possible améliorer celle-ci.

[13thFloor]

Hello,
+1 avec FSiebert.
Quand je suis confronté à ce problème (souvent), je cherche le sql_id qui a provoqué une consommation trop élevée de temp avec, par exemple, la requête suivante :

Code :

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

1
2
3
4
5
6
 
select sql_id,sample_time,TEMP_SPACE_ALLOCATED/(1024*1024*1024) gig
from DBA_HIST_ACTIVE_SESS_HISTORY
where sample_time > sysdate-8 
and TEMP_SPACE_ALLOCATED > (10*1024*1024*1024)
order by 2;

[FSiebert]

Merci 13thFloor.

Par contre, attention à l'utilisation de DBA_HIST_ACTIVE_SESS_HISTORY (et autres) qui, sauf erreur de ma part, nécessite le Diag Pack.

[jkofr]

Merci 13thFloor.

Par contre, attention à l'utilisation de DBA_HIST_ACTIVE_SESS_HISTORY (et autres) qui, sauf erreur de ma part, nécessite le Diag Pack.

Voui, je confirme!
jko

[zidane2012]

Hello,
+1 avec FSiebert.
Quand je suis confronté à ce problème (souvent), je cherche le sql_id qui a provoqué une consommation trop élevée de temp avec, par exemple, la requête suivante :

Code :

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

1
2
3
4
5
6
 
select sql_id,sample_time,TEMP_SPACE_ALLOCATED/(1024*1024*1024) gig
from DBA_HIST_ACTIVE_SESS_HISTORY
where sample_time > sysdate-8 
and TEMP_SPACE_ALLOCATED > (10*1024*1024*1024)
order by 2;

Oui mais des requêtes trop rapides peuvent être loupées par le sampling 1/10 de l'ASH dans
dba_hist_active_session_history ...

[FSiebert]

Oui mais des requêtes trop rapides peuvent être loupées par le sampling 1/10 de l'ASH dans
dba_hist_active_session_history ...

D'un autre côté, une requête qui explose le TEMP risque de prendre un peu de temps à s'exécuter

[zidane2012]

En effet ma requete fait tout ce qui sollicitele TEMP:
Union ,max ,group by , fonction analytique , GTT et jointure de type hash.
Volume 13 millions de lignes.
2Go de PGA.
Il est pas gentil ce temp : des i/o et en plus il explose à 12Go...
Et en plus de tout ça Oracle fournit aucun outil ou advisor pour le tailler.

[zidane2012]

Bonjour
Quand est ce qu'il est recommandé d'utiliser plusieurs tempfiles(eg :5 tempfiles à 2 Go chacun) au lieu de 1 seul à 10 Go ?
merci