Gestion du Tablespace temp

Bonjour,

ce message est la suite de :
http://www.developpez.net/forums/d68...r-ora-00060-a/

Les données sont les suivantes
-la taille de ma base fait 56 177 Mo (l'ensemble de mes tablespaces),
-le tablespace temp fait 34 358 Mo, sa taille max et il est a 100 %

que dois-je faire ? (Metalink me propose seulement de l'augmenter, ou ajouter un fichier pour le tablesapce)

car :
-1) je trouve qu'il a déjà une taille honorable (+ de la moitie de la taille de la base)

-2) le "temp" prends tjrs la taille max que l'on lui alloue

-3)il me semblait qu'il ne pouvait pas être plein a 100% car il est gérer par Oracle, donc pourquoi est-il full ?

-4) qu'est-ce que cela implique un tablesapce temp full ?


Merci pour votre aide

T'utilise bien PGA_AGGREGATE_TARGET ?

PS : la prochaine fois continue dans ta discussion ce sera plus simple :mouarf:

Bonjour,

Citation:

---

-1) je trouve qu'il a déjà une taille honorable (+ de la moitie de la taille de la base)

---

Quel est le profil de l'applicatif ? Nb utilisateurs ? Nb utilisateurs concurrents ? Y a-t-il des tris volumineux ?

Citation:

---

-2) le "temp" prends tjrs la taille max que l'on lui alloue

---

Par quel biais vois tu celà (console, script ?) et si par script quelle est la requête exacte te permettant de déduire cela ?

Citation:

---

-3)il me semblait qu'il ne pouvait pas être plein a 100% car il est gérer par Oracle, donc pourquoi est-il full ?

---

Je ne vois pas bien le lien entre le fait qu'un tablespace temporaire soit plein et le fait qu'il soit géré par Oracle peux-tu préciser à l'occasion le fond de ta pensée ? Quoiqu'il en soit ça peut être le cas si de nombreux extents sont alloués : la taille du segment temporaire sera alors celle de la somme de tes datafiles.

Citation:

---

-4) qu'est-ce que cela implique un tablesapce temp full ?

---

Tout et rien : si tous les extents du segment sont utilisés simultanément certains tris risquent de ne pas se terminer dans des temps acceptables, voire pas se terminer du tout. En revanche, un tablespace TEMP plein à 99 ou 100% ne signifie pas que tout l'espace temporaire est utilisé en même temps à un instant t et n'est pas forcément problématique.
Pour avoir une idée plus précise de l'utilisation de l'espace temporaire, peux-tu nous dire ce que donne :

Code:

---

1 2 3 4

show parameter pga show parameter area_size select tablespace_name, extent_size, current_users, total_extents, used_extents, added_extents, extent_hits, freed_extents, max_size, max_used_size, max_sort_size from v$sort_segment; select username, tablespace, contents, seg_type, extents from v$tempseg_usage;

---

EDIT : et combien de tempfiles composent ton tablespace, quelle est leur taille, sur quel système de fichiers sont-ils hébergés et sous quel OS ?

désolé pour le temps de réponse, mais beaucoup de problèmes a gérer la semaine dernière.

orafrance :
Je n'étais pas sur que les 2 problèmes étaient liés.

dans mon fichier spfile<SID>.ora, jutilise bien ce paramêtre :
pga_aggregate_target=134217728

Mathias44 :
-1
Quel est le profil de l'applicatif ? extration de donnée SAP pour intergrer dans BO
Nb utilisateurs ? une dizaine
Nb utilisateurs concurrents ? Pas de concurrence chez nous, nous sommes tous frères et égaux ;-) plus sérieusement je ne sais pas
Y a-t-il des tris volumineux ? oui, de gros tris et très volumineux

-2, je voulais dire que je ne mettrais pas le tablespace en autoextend, car après il impossible de gérer sa taille, et par conséquent de gérer le file system qui est derrière.
Comment je le vois : une erreur d'autoextend

-3 je pensais qu'un tablespace temp ne pouvait pas atteindre 100%.

-4
SQL> SHOW parameter pga

NAME TYPE VALUE
------------------------------------
pga_aggregate_target |big integer|128M

SQL> SHOW parameter area_size

NAME TYPE VALUE
------------------------------------
bitmap_merge_area_size|integer|1048576
create_bitmap_area_size |integer|8388608
hash_area_size |integer|131072
sort_area_size|integer|65536
workarea_size_policy|string|AUTO

SQL> SELECT tablespace_name, extent_size, current_users, total_extents, used_extents, added_extents, extent_hits, freed_extents, max_size, max_u sed_size, max_sort_size FROM v$sort_segment;

TABLESPACE_NAME EXTENT_SIZE CURRENT_USERS
-----------------------------------------
TEMP 128 0


TOTAL_EXTENTS | USED_EXTENTS |ADDED_EXTENTS |EXTENT_HITS|FREED_EXTENTS |MAX_SIZE |MAX_USED_SIZE |AX_SORT_SIZE
------------------------------------ ------------------------------------
32766|0 |31603 |332595|0|32766|32766|32420

SELECT username, tablespace, contents, seg_type, extents FROM v$tempseg_usage; ne fonctionne pas


J'ai un tempfile de 32 G et des brouettes, je suis sous rhel 4 en lvm.

Ce n'est pas dramatique un tel TEMP, même si cela peut paraitre inquiétant par rapport à la taille de tes datafiles.
Cet espace dit temporaire est utilisé, notamment, lors des tris (order by, distinct, opérateurs ensemblistes, create index...) et lors du parallélisme.
Il se peut que tu aies eu des créations d'index volumineux, voire des méga-select avec des clauses order by, sum, avg... et/ou du parallélisme un poil trop poussé.
Ce TEMP aussi élevé n'est qu'un high water mark. A un instant t ta base a utilisé 32 Go.
Pour revenir à un espace plus "digne", crée un autre tablespace temp, modifies les default_temporary tablespaces des users puis détruit l'ancien temp.
SI tu veux garder le même temp, fais l'opération inverse.

Bonjour,

128 Mo dePGA pour faire du SAP !!!

etonnant

tu n'a jamais essayé de faire des chez le support offiel de SAP ?

si non

pour voir si c'est sous sizé ou pas

Code:

---

1 2 3 4

SELECT round(PGA_TARGET_FOR_ESTIMATE/1024/1024) target_mb, ESTD_PGA_CACHE_HIT_PERCENTAGE cache_hit_perc, ESTD_OVERALLOC_COUNT FROM v$pga_target_advice;

---

et

Code:

---

1 2 3 4 5

SELECT LOW_OPTIMAL_SIZE/1024 low_kb,(HIGH_OPTIMAL_SIZE+1)/1024 high_kb, optimal_executions, onepass_executions, multipasses_executions FROM v$sql_workarea_histogram WHERE total_executions != 0;

---