expertise tuning sql

Bonsoir les amis,

j'ai une requete dans ma base sous oracle 9ir2 comme suit
select distinct (col1) from matable
where col2=:1; elle est tres simple!!!!.

ma table est petite, est une table de reference, contient 223 lignes,
le plan d'execution me fait un acces full, avec le triplet suivant:
(cost,io,cpu)= (12500,38000,1224), je voulais créer un index sur la colonne
col2, le nouveau plan d'execution, me fait un range scane et le triplet (cost,io,cpu)devient (221,1100,4800), je remarque que le cost et io deviennent meilleurs par rapport avant, par contre la cpu a été multipliée par 4 beacoup plus qu'avant, je ne sais pas si cet index est bon ou non? et dans ce cas sur quel critere je me base? sur le cost et io ou sur le triplet? sachant qu'on ma dit qu'il ne faut ps tenir compte trop sur le cost!!!!!!, qu'est que vous pouvez me conseiller pour ce cas svp? l'index est-il benefique?


une autre info, le db_block_read_count est a 32.

Merci d'avance pour votre aide

Quelle est la version Oracle utilisée ?

Théoriquement c'est le coût le plus faible qui est le meilleur en supposant que l'optimiseur fait une bonne estimation du coût de la requête. En pratique, il faut surtout prendre en compte la configuration requête, index, calcul des statistiques et paramètres pour l'optimiseur qui donne l'exécution la plus rapide dans le contexte d'exécution le plus proche possible des conditions réelles. La meilleure façon d'analyser le temps d'exécution d'une requête c'est la trace SQL et tkprof.

Bonjour,

select distinct (col1) from matable
where col2=:1; elle est tres simple!!!!.


Effectivement, elle est simple et meme avec un full ca me parait fort comme cost.

-1/ Faire le test en créeant un index sur Col2,Col1 comme ca tu as la clause where & la clause select en un seul scan.
-2/ Avant de faire le plan, il faut relancer un analyze de la table pour avoir des stats à jours.
-3/ Attention si cette table à fait l'object de beaucoup d'insert , puis delete,... le hig water Mark peut être élévé.
un petit select table_name, num_rows, blocks, last_analyzed from user_tables where table_name ='MATABLE' (bien mettre le nom de la table en majuscule).
Si le nb de blocs est élevé, alors pour remettre le hig water mark à niveau :
- faire un move de la table sur le tablespace (en pensant à faire un rebuild des indexes après) + analyze de la table + refaire la requete sur user_table pour vérifier l'impact + plan d'execution.

Voila ces quelques pistes !
D'un autre coté avec une taille de blocks de 32, on doit pas être loin de ramener la table avec un un seul blocks et donc le full scan n'est pas couteux.

Bonsoir les amis,

Merci pour ces réponses precieuses, je vais essayer et je vous informerai du resultat
merci