Question sur un plan d'exécution

**pacmann** · 17/11/2008, 19h41

Bonjour !

Ma requête : (retouchée pour garder l'anonymat

)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
SELECT *
FROM MaTable A JOIN MaTable B
  ON a.id_compte = b.id_compte
 AND a.etat = b.etat
WHERE a.id_compte = (SELECT id_compte FROM TableRef C WHERE nom_compte = 'X')
ORDER BY a.unchamp

Donne le plan d'exécution suivant :

SELECT STATEMENT 1 142 179K
SORT ORDER BY 1 142 179K
HASH JOIN 1 142 179K
TABLE ACCESS BY INDEX ROWID MaTable 3802 193K 1104
INDEX RANGE SCAN IndexTable1 15209 79
TABLE ACCESS BY INDEX ROWID TableRef 1 33 2
INDEX UNIQUE SCAN IndexRef1 1 1
TABLE ACCESS FULL MaTable 1897K 162M 178K

C'est pas très lisible, mais l'important est de voir que le CBO choisit FTS alors que ça aurait été sympa de lire IndexTable1...

Ce qu'il faut noter, c'est que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(SELECT id_compte FROM TableRef C WHERE nom_compte = 'X')

Renvoie une seule ligne. (y'a un index unique)

Maintenant, si on substitue directement la valeur, ça donne la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
SELECT *
FROM MaTable A JOIN MaTable B
  ON a.id_compte = b.id_compte
 AND a.etat = b.etat
WHERE a.id_compte = 378
ORDER BY a.unchamp

Et là, le plan correspondant est :

0 SELECT STATEMENT 1 142 2217
1 SORT ORDER BY 1 142 2217
2 HASH JOIN 1 142 2211
3 TABLE ACCESS BY INDEX ROWID MaTable 3802 193K 1104
4 INDEX RANGE SCAN IndexTable1 15209 79
5 TABLE ACCESS BY INDEX ROWID MaTable 3802 334K 1104
6 INDEX RANGE SCAN IndexTable1 15209 79

=> C'est ce dont on a toujours rêvé !

Est-ce que quelqu'un sait pourquoi ?
A vrai dire, je n'ai pas ce problème en général : je stocke l'identifiant du compte dans une variable. Mais il s'agit là d'une vieille requête...

Ce que j'aimerais, c'est avoir une explication rationnelle du phénomène, ce qui me fournirait des arguments solides pour ensuite convaincre mes amis de faire attention à ce "détail".

PS : comme on a en ce moment des petits problèmes de perf, on a un peu de mal à savoir ce qui est vraiment du à des requêtes pourries, ou a des problèmes de stats, ou des paramètres systèmes, ...

Merci !

**Waldar** · 17/11/2008, 19h57

Envoyé par pacmann

C'est pas très lisible, mais l'important est de voir que le CBO choisit FTS alors que ça aurait été sympa de lire IndexTable1...

Ce qu'il faut noter, c'est que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

(SELECT id_compte FROM TableRef C WHERE nom_compte = 'X')

Renvoie une seule ligne. (y'a un index unique)

Notez bien que le FTS a été fait sur la table de référence.

Vous avez, j'imagine, un index unique sur TableRef.id_compte mais aucun index sur TableRef.nom_compte, qui est la valeur filtrée.

Essayez un index (pas forcément unique) sur TableRef.nom_compte et remontrez-nous le plan.

**pacmann** · 17/11/2008, 20h03

Oops, je me suis planté quand j'ai remplacé les noms de mes tables par leur fausses identités respectives...

Par ailleurs, il y a bien un index sur la grosse table : les deux côtés de la jointure accèdent à la même table, selon les mêmes critères. Et la première fois, l'accès est bien fait par l'index sur le compte...

(j'édite le poste initial pour rétablir la vérité)

**Waldar** · 17/11/2008, 20h33

Autre tentative, je n'y crois pas beaucoup mais essayons :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

WHERE a.id_compte = (SELECT C.id_compte FROM TableRef C WHERE C.nom_compte = 'X')

Que donnerait le plan d'exécution de la requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SELECT *
FROM MaTable A JOIN MaTable B
  ON a.id_compte = b.id_compte
 AND a.etat = b.etat
    JOIN TableRef c
  ON a.id_compte = c.id_compte
WHERE c.nom_compte = 'X'
ORDER BY a.unchamp

**pacmann** · 17/11/2008, 21h12

Non plus !

(J'ai tenté les deux variantes)

Et en fait, le plus important n'est pas la requête gagnante, puisqu'on l'a déjà...
(à savoir commencer par récupérer l'identifiant dans une variable, puis passer la variable dans la jointure).
Le fait est surtout que la différente de comportement me surprend beaucoup...

**fatsora** · 18/11/2008, 09h46

quelle est ta version Oracle

les parameters cursor_sharing , optimizer_mode etc

voir

http://www.oracloid.com/2006/07/bind...no-histograms/

**pacmann** · 18/11/2008, 14h01

Merci pour ta réponse.

cursor_sharing : exact
optimizer_mode : choose.

Concernant l'article, il parle de bind variable peeking, non ?
Est-ce que tu peux m'en dire un peu plus sur le lien avec mon problème ?

Je suppose qu'il pourrait y avoir un problème si l'optimiseur se trompait dans la sélectivité de la sous requête de sélection du compte :
par rapport à cela, il y a deux points que je voudrais souligner :
- num_rows / num_distinct = 1 pour cette colonne
- il y a un unique index sur la colonne...

EDIT : Ok, je crois que j'ai compris où tu voulais en venir !
En gros, il se pourrait qu'il prenne le plan d'exécution adéquat pour un autre compte, pour lequel la sélectivité sur la grosse table est faible...
Cela dit, vu qu'on donne exactement les même filtres pour les deux côtés de la requête (sur la même grosse table), je ne vois pas pourquoi il utiliserait le procédé une seule fois...

Cela dit, je vais voir si on peut jeter un oeil au 10053...

**pacmann** · 19/11/2008, 15h01

Coucou, je reviens à la charge !

Bon, je suis pas très fort pour décrypter la trace brute... donc j'ai tenté d'autres trucs.

On a importé / exporté les stats de PROD vers l'environnement de test.
Et là, tous les accès ce font par index !
Bon, on a donc cherché ce qui pouvait différer entre la prod et le test dans les paramètres de l'optimiseur... et rien.

Par contre, on a constaté qu'il y avait un index supplémentaire en prod (oui, je sais...) !

En résumé :
Avec 2 index : on full scanne
Avec 1 index : on lit l'index

Ca me dépasse... Quelqu'un a une idée ?
(En atttendant, on va essayer de faire un effort pour se retaper la trace...)

**pacmann** · 21/11/2008, 09h34

Petite question bonus :
Est-ce qu'il y a un outil quelconque pour mettre en forme la 10053 ?
Ou éventuellement des astuces pour le mettre en forme à la main ?
(On m'a dit que tkprof ne le fait pas...)

**farenheiit** · 03/11/2009, 16h08

je rebondis sur la dernière question de pacman car ça m'interesse.
Comment lire et interpréter une trace 10053.
y'a t'il un outil équivalent à Tkprof ?
Par ailleurs PACMAN as tu trouvé une solution à ton pb ? Avec 2 indexes => FTS avec un seul INDEX => Range Scan

**mnitu** · 04/11/2009, 09h12

Envoyé par farenheiit

je rebondis sur la dernière question de pacman car ça m'interesse.
Comment lire et interpréter une trace 10053.
y'a t'il un outil équivalent à Tkprof ?
Par ailleurs PACMAN as tu trouvé une solution à ton pb ? Avec 2 indexes => FTS avec un seul INDEX => Range Scan

C'est vieux (Oracle 8i) mais c'est bien expliqué: Wolfgang Breitling, A Look under the Hood of CBO-10053 Event, http://www.centrexcc.com
Il y a aussi des discutions sur Ask Tom et ailleurs sur l'internet. Mais c'est rarement utile pour des problèmes pratiques.

**farenheiit** · 04/11/2009, 09h43

J'ai mieux: le chapitre 7 "Event 10053 and the cost based optimizer" du livre de Norbert DEBES "Secrets of the Oracle database"
http://www.apress.com/book/view/9781430219521
c'est expliqué plus simplement que dans le livre de Johnathan LEWIS et en plus c'est en 10GR2

**mnitu** · 04/11/2009, 10h35

Envoyé par farenheiit

J'ai mieux: le chapitre 7 "Event 10053 and the cost based optimizer" du livre de Norbert DEBES "Secrets of the Oracle database"
http://www.apress.com/book/view/9781430219521
c'est expliqué plus simplement que dans le livre de Johnathan LEWIS et en plus c'est en 10GR2

Je ne trouve pas le chapitre 7 en téléchargement mais seulement le chapitre 1.

**farenheiit** · 04/11/2009, 10h39

Je l'ai trouvé sur sur Emule

Question sur un plan d'exécution

SQL Oracle

Discussions similaires

Partager

Partager