Discussion :

[Cobra13530]

Bonjour a tous,

j'aurais besoin de votre aide.
J'ai une table avec 5 index, je ne peux pas modifier ces index car se sont des index proprietaires d'une appli, enfin je veux dire par la qu'il me faudrait l'accord de l'editeur pour les supprimer.
Mais avant d'arriver à ce cas de figure voila ce que j'ai trouve

BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR
------ ----------- ------------- ----------------------- ----------------------- -----------------
     3       74507      10169429                       1                       1           3908080
     3       87950         39016                       9                    1040           9735411
     2       45944         39016                       2                     461           9741489
     2       39937         84429                       1                       3            254462
     3       93942         39016                       6                     677           9798418
     3       99502      10527236                       1                       1           6765295

Le chiffre BLEVEL me semble important comparer aux autres index de la base
Ensuite le parametre AVG_LEAF_BLOCKS_PER_KEY, a quoi correspond t'il exactement ?
Les performances se sont degrades depuis quelques temps et nous cherchons la cause
Cette table est bcp appellée.

Merci d'avance à tous

[Cobra13530]

Une derniere question, si l'index est supprime et recree cela spprime t'il le niveau BLEVEL etc ...

[Pomalaix]

...Le chiffre BLEVEL me semble important comparer aux autres index de la base
Ensuite le parametre AVG_LEAF_BLOCKS_PER_KEY, a quoi correspond t'il exactement ?...

En quoi 3 est-elle une grosse valeur ?
AVG_LEAF_BLOCKS_PER_KEY, comme l'indique la doc, est le nombre moyen de blocs dans lesquels figurent une même valeur.
Plus cette valeur est élevée, plus cela indique que vous avez des valeurs répétitives dans les données indexées.

Rien ne vous empêche de reconstruire vos index par ALTER INDEX xxx REBUILD.

Cependant, je pense que vous prenez les choses par le mauvais bout : rien ne vous permet d'incriminer les index plus qu'autre chose, surtout que j'ai l'impression que vous vous basez sur des pratiques datant de l'an pépin, et quelque peu révolues. Pourquoi s'intéresser spécifiquement au BLEVEL (qui dans votre cas n'a rien d'anormal)?

[Cobra13530]

Oupsss quel acceuil !!

Certes mes pratiques sont peut etre anciennes, mais apres quelques annees d'interruption sur oracle, je reviens petit à petit (je m'etais arreté a la version 9i )

pourquoi je pense que ce sont les index qui sont en cause c'est parce que sur cette table il y 5 index et oracle ne choisit pas le bon d'ou la perte de perfo.

Selon vous quelle piste devrais je choisir ?

Cordialement

[pachot]

Bonjour,
Il faudrait voir la requête avec son plan d'exécution, et pourquoi elle n'utilise pas le bon index. Une hauteur de 2 ou 3 est normale sur un gros index.
Cordialement,
Franck.

[petitfrere]

sans toucher a l'appli, vous pouvez rendre invisible un index, ou mieux utiliser sql_plan pour force un PL pluto qu'un autre, (toujours sans toucher a l'appli)

[Cobra13530]

en fait le probleme venait des statistiques.
Desormais le traitement qui prenait 5h ne prend plus que 15min.
Je ne sais pas ce qui a ete fait exactement mais parait il que c'est un bug d'Oracle 11 ?
Connaissez vous ce bug ? si bug il y a ?