acces by index est-il normal

[startout]

Bonjour à tous,

Je suis sur Oracle 10g.
J'étudie l'optimiseur sur une simple requête :

Code :

1
2
 
SELECT * FROM client,contrat WHERE nom='X' AND client.numclient=contrat.refclient ;

J'obtiens le plan suivant :

Code :

1
2
3
4
5
6
7
 
Nesteed loops
   TABLE access contrat Full
   TABLE access client BY INDEX rowid
           Nom='X'
           INDEX  Pk_client UNIQUE scan
                  client.numclient=contrat.refclient

Mes tables ne contiennent pas beaucoup de données (au max 5 tuples par table).
Mon client 'X' apparaît 3 fois dans ma table client.
Mes stats sont à jour et le paramètre optimizer_mode est à choose.

Pourquoi l'optimiseur me fait passer par l'index alors qu'il me semblait un full table scan sur de petite table est préférable ?

Je vous remercie par avance pour votre aide.
cordialement
Startout

[Gaadek]

Salut,

Avec un index, le SGBD évalue le coût d'utilisation des index par rapport à celui de parcours de la table.

Effectivement, en général, sur des petites tables, un index est inutile car moins performant qu'un full scan. Cependant, 2 remarques:
1) Pourquoi mettre en place des mécanismes qui ne sont pas adaptés? Et pourquoi vouloir étudier le fonctionnement de l'optimiser dans des conditions anormales?
2) Au niveau du plan d'exécution, essayez de supprimer l'index, de relancer le plan et de comparer les couts (temps et mémoire). Comparez, et vous verrez qu'il y a peut être une différence.

Dans votre exemple, vu que votre index va servir à scinder la table en 2, je dirais que l'optimiser est pas nécessairement déconnant

[startout]

Je vous remercie pour votre aide.
Je teste dans des conditions anormales car je n'ai pas de jeux de données.
Les datasets trouvés sur le net et sur ce forum ne me satisfait pas.

Ceci est pour mon rapport de stage. Je dis dans celui-ci que l'optimiseur va privilégier le FTS lorsqu'on dispose de petite table malgré que l'index soit créé.
Mais j'essaye de trouver le plan d'execution qui le démontre sans tricher (suppression des index).

SQL dev me propose uniquement un repère cout.
avec index => 4
sans index => 7

Sans ma clé primaire, il effectue la jointure avec un hash join. Je comprends encore moins. Je croyais que le hash join était intéressant quand les deux tables sont volumineuses.

Je crois que j'ai encore du boulot avant d'être opé sur Oracle...

[ojo77]

Bonjour,

Avez-vous calculé vos statistiques avec des histogrammes ?
Combien de lignes avez-vous par blocs de données ?
Les statistiques systèmes ont-elles été calculées ?
Quelles sont les valeurs de Vos paramètres optimizer_index_caching et optimizer_index_cost_adj ?

Tous ces éléments peuvent influer sur le plan d'exécution.