Cout d'un INSERT

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

Citation:

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

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 :koi:

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

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 :koi: