Cout d'un INSERT

[Wurlitzer]

Je suis sous Oracle8i.

J'ai une table très simple avec juste une PK et une FK.

La particularité de cette table, c'est qu'en permanence il y a de nouveaux enregistrements qui sont insérés alors que d'autres sont supprimés.

Le niveau moyen de remplissage de la table est entre 0 et 10 000 lignes mais il y a des centaines de milliers de lignes qui transitent par cette table chaque jour.

Lorsque je regarde le coût d'un INSERT dans cette table l'optimizer m'affiche 979. Ce qui me parait délirant pour un simple INSERT.

Si créé une seconde table avec exactement les mêmes caractéristiques le coût de l'INSERT est de 1. Ce qui me plaît evidemment mieux.

J'ai donc plusieurs questions :

- Qu'est ce qui fait que mon coût se dégrade ?

- Est ce que cela a un vrai impact sur les performances ? J'ai fait un test en autotrace et j'ai pas vu de différence entre mes deux tables.

- Si cela a un impact, quelles sont les paramètres à ajuster pour éviter que mon coût ne se degrade.

Merci de votre aide & bon WE

[pifor]

Envoyé par Wurlitzer

- Si cela a un impact, quelles sont les paramètres à ajuster pour éviter que mon coût ne se degrade.

Il faudrait aussi essayer de tracer le SQL et d'utiliser TKPROF pour avoir les vrais coûts d'exécution (disque, cache, waits).

Une cause possible pourrait être la gestion de l'espace libre dans les blocs
(à confirmer par l'analyse des waits: voir http://download-west.oracle.com/docs...1_res.htm#1091

[Wurlitzer]

Merci de ta réponse, je vais essayer de traquer les waits pour en savoir plus.

Oui c'etait aussi mon idée que cela pouvait venir de la gestion des l espace libre mais j'ai pas encore les idées assez clair pour bien comprendre ce qui se passe.

Voici quelques informations en plus et quelques questions aussi pour essayer de faire avancer le débat.

Comme je l'ai dit ma table à entre 0 et 10 000 lignes statistiquement elle plus souvent 0 ligne mais c'est bien sur quand elle est rempli que cela devient important pour l'application.

Comment feriez vous pour calculer les stats sur une table aussi fluctuante ?

Si je les calcule au hasard je risque d'avoir des stat a 0 ligne qui ne seront peut etre pas efficace quand la table a 10 000 lignes. Si j'essaye de les calculer à 10 000 lignes. Il faut d'une part que je sois la au bon moment et j'ai aussi le risque non negligeable que qqun d'autre les recalcule "par hasard" au mauvais moment. Je pense de plus en plus mettre un hint RULE sur les requete qui utilise cette table. Vous en pennsez quoi ?

Par ailleurs connaissez vous une bonne doc qui explique en detail les statistiques .

Pour ma fameuse table qui a pour l'instant une seule ligne. J'ai

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
 
OWNER                 : MONOWNER                      
TABLE_NAME            : MATABLE         
TABLESPACE_NAME       : MONTABLESPACE                                              
CLUSTER_NAME
IOT_NAME
PCT_FREE              : 10
PCT_USED              : 40                                     
INI_TRANS             : 1
MAX_TRANS             : 255  
INITIAL_EXTENT        : 26214400
NEXT_EXTENT           : 26214400      
MIN_EXTENT            : 1
MAX_EXTENT            : 121  
PCT_INCREASE          : 0                 
FREELIST              : 1
FREELIST_GROUPS       : 1                                      
LOGGING               : YES     
BACKED_UP             : N        
NUM_ROWS              : 1                                      
BLOCKS                : 6249                                   
EMPTY_BLOCKS          : 150 
AVG_SPACE             :7947
CHAIN_CNT             : 0
AVG_ROW_LEN           : 21
AVG_SPACE_FREELIST_BLOCKS : 7947                                  
NUM_FREELIST_BLOCKS       : 6249
DEGREE                : 1       
INSTANCE              : 1     
CACHE                 : N 
TABLE_LOCKS           : ENABLED   
SAMPLE_SIZE           : 1                                      
LAST_ANALYZED         : 18/12/2006 08:00:08 
PARTITIONED           : NO                      
IOT_TYPE 
TEMPORARY             : N        
SECONDARY             : N         
NESTED                : NO     
BUFFER_POOL           : DEFAULT     
ROW_MOUVEMENT         : DISABLED    
GLOBAL_STATS          : NO 
USER_STATS            : NO     
DURATION                   
SKIP_CORRUPT          : DISABLED     
MONITORING            : NO 
CLUSTER_OWNER

J'aimerais en particulier comment je peux avoir NUM_ROWS = 1 (Logique puisque le count(*) me donne une ligne) et BLOCKS = 6249 (pourquoi pas) et EMPTY_BLOCKS a seulement 150 ! !

Pour moi comme ma table est vide je devrait avoir BLOCKS = EMPTY_BLOCKS. Mais visiblement je n'ai rien compris

[pifor]

L'intérêt d'avoir des statistiques pour une table uniquement pour optimiser INSERT me semble limité parce qu'il y a (très) peu de façon différentes de faire un INSERT en SQL sur une table (à part le chargement direct par SQL*Loader qui ne fait pas un "vrai" INSERT ou peut-être les tables partitionnées ?).

Le fonctionnement de l'optimiseur et le calcul des statistiques pour la 8i est documenté dans http://download-west.oracle.com/docs...a76992/toc.htm

[remi4444]

t'es sur que l'analyse n'est pas faite à un moment ou la table est vide ??

Sinon peut etre que tu pourrais monter le PCT-USED histoire que ça libère plus de place lors des deletes...

Autre chose si tu ne fais pas d'update, mets ton pctfree à 0.

mais bon c'est bizarre quand meme