Problème de performance sur SELECT avec jointures - Page 2

jalaval · 16/12/2011, 13h55

Citation:

Envoyé par mnitu

C'est écrit de le début 4.173.000 /
Peut être qu’en changeant de stratégie (= de requête) on pourrait gagner quelque chose de plus.

Voici le plan d'execution pour la même requete avec un type de document différent, beaucoup moins représenté dans la table Document :

Code :

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

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
PLAN_TABLE_OUTPUT
SQL_ID  2r597zddqdwd9, child number 0
-------------------------------------
SELECT         *      FROM         ( SELECT             DISTINCT pensionne0_.ID_PENSIONNE AS ID1_5_,             pensionne0_.BLOC_NOTE AS BLOC2_5_,             
pensionne0_.DATE_DECES AS DATE3_5_,             pensionne0_.DATE_NAISS AS DATE4_5_,             pensionne0_.ID_PENSIONNE_TMP AS ID5_5_,             
pensionne0_.ID_SERVICE AS ID6_5_,             pensionne0_.NOM_MARITAL AS NOM7_5_,             pensionne0_.NOM_PATRONYME AS NOM8_5_,             
pensionne0_.PRENOMS AS PRENOMS5_          FROM             PENSIONNE pensionne0_          LEFT OUTER JOIN             SOUS_DOSSIER sousdossie1_                 
 ON pensionne0_.ID_PENSIONNE=sousdossie1_.ID_PENSIONNE          LEFT OUTER JOIN             DOCUMENT documentco2_                  ON 
sousdossie1_.ID_SOUS_DOSSIER=documentco2_.ID_SOUS_DOSSIER          WHERE             pensionne0_.ID_SERVICE='059000'              AND 
documentco2_.ID_TYPE_DOCUMENT='150'          ORDER BY             pensionne0_.ID_PENSIONNE )      WHERE         rownum <
 
Plan hash value: 778032787
 
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                         | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  | Writes |  OMem |  1Mem | Used-Mem | Used-Tmp|
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|*  1 |  COUNT STOPKEY                    |                   |      1 |        |    100 |00:00:19.02 |     179K|    177K|    403 |       |       |          |         |
|   2 |   VIEW                            |                   |      1 |   8535 |    100 |00:00:19.02 |     179K|    177K|    403 |       |       |          |         |
|*  3 |    SORT ORDER BY STOPKEY          |                   |      1 |   8535 |    100 |00:00:19.02 |     179K|    177K|    403 | 22528 | 22528 |20480  (0)|         |
|   4 |     SORT UNIQUE                   |                   |      1 |   8535 |  13793 |00:00:18.99 |     179K|    177K|    403 |  2210K|   780K| 1964K (0)|         |
|*  5 |      HASH JOIN                    |                   |      1 |   8535 |  17196 |00:00:18.90 |     179K|    177K|    403 |  4740K|  1518K| 7739K (0)|    3072 |
|*  6 |       HASH JOIN                   |                   |      1 |    116K|    100K|00:00:17.39 |     160K|    158K|      0 |  3861K|  1994K| 6715K (0)|         |
|   7 |        TABLE ACCESS BY INDEX ROWID| DOCUMENT          |      1 |    116K|    101K|00:00:04.46 |   72317 |  71902 |      0 |       |       |          |         |
|*  8 |         INDEX RANGE SCAN          | IN_DOC_TYPEDOC    |      1 |    116K|    101K|00:00:03.25 |     638 |    638 |      0 |       |       |          |         |
|   9 |        TABLE ACCESS FULL          | SOUS_DOSSIER      |      1 |   8345K|   8345K|00:00:00.01 |   88371 |  86837 |      0 |       |       |          |         |
|  10 |       TABLE ACCESS BY INDEX ROWID | PENSIONNE         |      1 |    345K|    360K|00:00:00.72 |   18734 |  18587 |      0 |       |       |          |         |
|* 11 |        INDEX RANGE SCAN           | IN_PENSIONNE_SERV |      1 |    345K|    360K|00:00:00.01 |    2403 |   2403 |      0 |       |       |          |         |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
Predicate Information (IDENTIFIED BY operation id):
---------------------------------------------------
 
   1 - filter(ROWNUM<=100)
   3 - filter(ROWNUM<=100)
   5 - access("PENSIONNE0_"."ID_PENSIONNE"="SOUSDOSSIE1_"."ID_PENSIONNE")
   6 - access("DOCUMENTCO2_"."ID_SOUS_DOSSIER"="SOUSDOSSIE1_"."ID_SOUS_DOSSIER")
   8 - access("DOCUMENTCO2_"."ID_TYPE_DOCUMENT"=150)
  11 - access("PENSIONNE0_"."ID_SERVICE"='059000')

Le nombre d'occurence de la valeur id_type_document=150 dans la table document est de :

Code :

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

 SELECT count(*), count(case Id_TYPE_DOCument when 150 then 1 end)  FROM document ==> 101073

Nous pourrions envisager de demander à l'utilisateur d'affiner ses critères de recherches dans le cas ou sa demande renverrait plus de 100 réponses.

La question est : Comment savoir à l'avance combien de lignes la requete va renvoyer ?
Faire un count coute quasiment aussi cher que ramener les lignes.

Voyez vous un un moyen de résoudre cette problématique ?

Par exemple, est il possible d'interroger dans un programme Java le plan d’exécution d'une requête ou bien les données statistiques ?

Rams7s · 16/12/2011, 14h08

Perso, je tenterai bien un index sur documents(id_type_document,id_sous_dossier) au lieu de l'index sur documents(id_type_document).

Pour le requetes ou le numero de type_document est peu present, on aurait le meme effet. Et pour les requetes genre celle ou vous avec id_type_document=10 qui renvoie tout plein de resultats, ca permettrait peut-etre d'utiliser l'index, en un "fast full-index scan" vu que toutes les infos seraient dedans.
Parce que la concretement, il peut pas l'utiliser pour id_type_document=10.

Edit:Et d'ailleurs, tant qu'on y est:

SOUS_DOSSIER(ID_PENSIONNE,ID_SOUS_DOSSIER )Mais pour l'ordre des colonnes, la je suis pas tres convaincu. Mais bon, visiblement c'est pas ca qui prends du temps, ce qui est marrant d'ailleurs...

jalaval · 16/12/2011, 14h39

Merci pour cette piste.
Cependant, j'ai créé l'index documents(id_type_document,id_sous_dossier), mais cela ne change rien au plan d’exécution : ce nouvel index n'est pas utilisé.

Mohamed.Houri · 16/12/2011, 14h39

Citation:

Envoyé par ORA-007

Bonjour,

PS2 : Quelqu'un sait il le seuil à partir duquel Oracle fait un FULL SCAN et quel parametre le régit ?

Vous avez votre réponse dans l'article suivant de jonathan Lewis

http://jonathanlewis.wordpress.com/category/philosophy/

Que je viens de traduire à l'instant

Traduction

Si vous exécutez une requête qui est supposée retourner un seul enregistrement à partir d'une très large table, et, vous disposez d'un index approprié sur cette table, vous vous attendrez probablement à ce que l'optimisateur d'Oracle identifie l'index et qu'il l'utilise. Si vous changez votre requête de telle sorte qu'elle renvoi tous les enregistrements de cette table (sans tri) vous vous attendrez probablement à ce que l'optimisateur d'Oracle choisisse un full table scan.

Ceci conduit à la très simple idée qui est souvent ignorée

"Quelques fois il suffit juste d'un enregistrement supplémentaire pour passer d'un plan d'exécution utilisant un index à un plan utilisant un full table scan"

Il existe un point où l'optimisateur change d'un accès indexé à un seul enregistrement vers un accès à toute la table pour tous les enregistrements.

Si vous êtes assez chanceux et le modèle de l'optimisateur est parfait il n'y aura aucun effet significatif sur la performance, bien sûr. Mais, nous ne sommes pas aussi chanceux que ça, et c'est pour cette raison que les gens finissent par poser la question : 'Comment le plan d'exécution est devenu subitement non performant, il n'y a eu aucun changement .... sauf pour un petit supplément de données?". Tout ce qu'il faut c'est un seul enregistrement (que l'optimisateur reconnait) pour changer d'un plan d'exécution à un autre- et parfois l'optimisateur trouve le mauvais moment pour opérer ce changement.

jalaval · 16/12/2011, 16h04

Je reformule ma question : Est il possible dans un programme (java ou autre) de connaitre le nombre de lignes qu'une requête va ramener, mais sans exécuter la requête (ie en se basant sur les statistiques) ?

Mohamed.Houri · 16/12/2011, 16h12

Si tant est que cela soit possible, comment être sûr dans ce cas que les statistiques sont à jour????

Je ne pense pas que ce que vous proposez soit possible. Il faudrait plutôt se concentrer sur l'amélioration de votre requête.

J'ai une question quand même : Est-ce que le client se plaint de la performance parce qu'il s'est habitué à voir cette requête s'exécuter rapidement ou bien c'est du premier coup qu'il s'est plaint de la performance?

jalaval · 16/12/2011, 16h19

Le client est en phase de recette de cette application, et considère comme une anomalie les temps de réponse de ce cas d'utilisation.

Il accepterait que le système renvoie un message à l'utilisateur lui précisant que le résultat de sa recherche va dépasser les 100 réponses et lui demandant d'affiner ses critères de recherches (sans que la recherche soit effectivement faite).

En ce qui concerne la validité des statistiques, ne sont elles pas maintenues à jour en permanence par Oracle ?

Mohamed.Houri · 16/12/2011, 16h20

Citation:

Envoyé par mnitu

C'est écrit de le début 4.173.000 /
Pas d'index parce que c'est un Hash Join.

Ce n'est certainement pas une nécessité ni une règle que la jointure HASH JOIN se fasse toujours via un FULL TABLE SCAN. Jonathan Lewis dans son livre Cost Based Oracle Fundamentals au Chapitre 12, Hash Join, page 321, parle(par l'exemple) justement de cette pas toujours vraie règle mais néanmoins largement répandue dans le monde Oracle

Rams7s · 16/12/2011, 17h25

Citation:

Envoyé par Mohamed.Houri

Je ne pense pas que ce que vous proposez soit possible. Il faudrait plutôt se concentrer sur l'amélioration de votre requête.

AMHA, un truc comme ca peut fonctionner, ca copie juste le fonctionnement de autotrace traceonly. Mais bon, qui dit explain plan, dit erreur possible aussi. Justement avec les statistiques.

Code :

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

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
--explain plan set statement_id='toto' for select * from tmp2;
SELECT cardinality, id,depth, position FROM plan_table WHERE statement_id='toto' ORDER BY id;
 
CREATE OR REPLACE FUNCTION tmp_func(p_param number) RETURN number IS
begin
   dbms_lock.sleep(0.1);
   RETURN 1;
end;
/
associate statistics WITH functions tmp_func DEFAULT selectivity 100;
DROP TABLE tmp2;
CREATE TABLE tmp2 AS SELECT level AS n FROM dual connect BY level<=100;
SET timing ON;
--set autotrace on
--select * from tmp2 where tmp_func(n)=1;
--Temps: 1000*0.1 = 10s
--set autotrace off
 
--set autotrace traceonly
--select * from tmp2 where tmp_func(n)=1;
--Temps: 1000*0.1 = 10s
--set autotrace off
 
 
EXPLAIN plan SET statement_id='miouf2' FOR SELECT * FROM tmp2 WHERE tmp_func(n)=1;
SELECT cardinality FROM plan_table WHERE statement_id='miouf2' AND id=0;

Bien entendu, dans ce cas la il faudra soit changer le statement_id, soit faire un tri sur le plan qui vous interesse.

Waldar · 16/12/2011, 18h21

Il faut bien définir votre besoin.
Si votre seuil d'affichage est de cent lignes, la première requête que je vous ai donné peut répondre rapidement : le calcul du tri avait un certain coût.
On peut aussi envisager un hint - je ne suis pas certain de l'impact cela dit :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SELECT /*+ FIRST_ROWS */
       pns.ID_PENSIONNE
     , pns.BLOC_NOTE
     , pns.DATE_DECES
     , pns.DATE_NAISS
     , pns.ID_PENSIONNE_TMP
     , pns.ID_SERVICE
     , pns.NOM_MARITAL
     , pns.NOM_PATRONYME
     , pns.PRENOMS
  FROM PENSIONNE pns  
 WHERE pns.ID_SERVICE = '059000'
   AND EXISTS (SELECT NULL
                 FROM SOUS_DOSSIER sdo
                      INNER JOIN DOCUMENT doc
                        ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                  AND doc.ID_TYPE_DOCUMENT = 10)
  AND ROWNUM <= 101;

Si vous atteignez la ligne 101, c'est que vous avez plus de cent lignes et vous pouvez afficher un message adéquat à l'utilisateur.

En y réfléchissant, même avec le type 150 vous arrivez à 13.000 lignes, il faut repenser votre besoin je pense.

skuatamad · 16/12/2011, 20h21

En soit ça ne me choque pas que la requête puisse ramener dans les 100 000 lignes tant qu'elle est paginée pour ne fetch que 100 lignes.
Après je ne vois pas pourquoi essayer de conserver la requête très innéficace d'hibernate.
En effet DISTINCT + LEFT JOIN avec filtre WHERE sur la table en LEFT JOIN (ce qui revient à faire un INNER JOIN...) montre que cette requête ne convient pas du tout.

Il faut partir de la requête de Waldar (hibernate peux executer des requêtes directement) et regarder son plan.
Il peut être intéressant de faire une trace level 12 + TKPROF pour voir ce qui se passe car apparemment le FULL SCAN de DOCUMENTS est qu'en même très lent.

Sinon j'utiliserais bien aussi le hint FIRST_ROWS(N) dans la requête de Waldar (de toute façon ça fournie juste plus d'info à l'optimiseur, ça ne fait donc pas de mal):

Code :

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

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
WITH SR AS
(
  SELECT /*+ FIRST_ROWS(100) */
         pns.ID_PENSIONNE
       , pns.BLOC_NOTE
       , pns.DATE_DECES
       , pns.DATE_NAISS
       , pns.ID_PENSIONNE_TMP
       , pns.ID_SERVICE
       , pns.NOM_MARITAL
       , pns.NOM_PATRONYME
       , pns.PRENOMS
    FROM PENSIONNE pns  
   WHERE pns.ID_SERVICE = '059000'
     AND EXISTS (SELECT NULL
                   FROM SOUS_DOSSIER sdo
                        INNER JOIN DOCUMENT doc
                          ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                  WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                    AND doc.ID_TYPE_DOCUMENT = 10)
ORDER BY pns.ID_PENSIONNE ASC
)
SELECT ID_PENSIONNE
     , BLOC_NOTE
     , DATE_DECES
     , DATE_NAISS
     , ID_PENSIONNE_TMP
     , ID_SERVICE
     , NOM_MARITAL
     , NOM_PATRONYME
     , PRENOMS
  FROM SR
 WHERE ROWNUM <= 100;

Après si c'est toujours très lent il est peut être envisageable de s'orienter vers une vue matérialisée qui pourrait réduire le travail à fournir pour la requête.

Juste un point, il me semble que tu disais que tu étais en recette, le serveur de recette est il ISO future PROD ? notemment concernant les disques.

pacmann · 19/12/2011, 19h34

Salut,

Je suis bien d'accord avec toi Waldar. Cela dit ce n'est pas forcément le besoin qui est mal exprimé, ça peut très bien être le modèle ou le "process".

Finalement, on voit souvent ce genre de problème : ton modèle est totalement normalisé, et tes critères de recherche (sans dépendances) sont éparpillés. T'es obligé de faire une VM comme le suggère Skuat.

La seule question qui reste c'est : est-il rationnel de faire une recherche sur la possession d'un type de document ? Quel est la fréquence d'une telle recherche ?

- Si c'est un cas d'exception, 50 secondes ne sont vraiment pas choquantes.
- Si c'est le quotidien du chargé, il faut faire une VM, et surtout se demander pourquoi on doit sortir en interactif la liste des gens qui ont eu un certain type de document...

jalaval · 20/12/2011, 11h28

Un grand merci à tous pour vos réponses pertinentes.
Je vais tester les différentes solutions/approches proposées et vous ferais un retour.

Concernant les différentes questions posées :

Citation:

Envoyé par skuatamad

Juste un point, il me semble que tu disais que tu étais en recette, le serveur de recette est il ISO future PROD ? notemment concernant les disques.

Notre serveur de recette est configuré pour être "aussi proche" de la production que possible, on peut donc s'attendre à des performances similaires.

Citation:

Envoyé par pacmann

La seule question qui reste c'est : est-il rationnel de faire une recherche sur la possession d'un type de document ? Quel est la fréquence d'une telle recherche ?

- Si c'est un cas d'exception, 50 secondes ne sont vraiment pas choquantes.
- Si c'est le quotidien du chargé, il faut faire une VM, et surtout se demander pourquoi on doit sortir en interactif la liste des gens qui ont eu un certain type de document...

C'est effectivement la question que devra se poser la MOA si l'on ne trouve pas de solution d'optimisation efficace.

pacmann · 20/12/2011, 12h00

Citation:

Envoyé par jalaval

C'est effectivement la question que devra se poser la MOA si l'on ne trouve pas de solution d'optimisation efficace.

Si je peux me permettre, à mon sens, la MOA pourrait (devrait ?) se poser cette question même si on trouve une optimisation.

A quoi ça sert ? Dans quel contexte ? Est-ce vraiment ce qu'on cherche dans notre process ? Notre process est-il bien design-gné ?
=> Ca a l'air intéressant en tant que MOA, non ?

jalaval · 20/12/2011, 14h28

Citation:

Envoyé par skuatamad

Il peut être intéressant de faire une trace level 12 + TKPROF pour voir ce qui se passe car apparemment le FULL SCAN de DOCUMENTS est qu'en même très lent.

Voici le résultat de la trace demandée :

Code :

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

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
"jla.txt" 122 lignes, 5099 caractères
 
TKPROF: Release 10.2.0.3.0 - Production ON Mar. Déc. 20 14:24:47 2011
 
Copyright (c) 1982, 2005, Oracle.  ALL rights reserved.
 
Trace file: gm2011_ora_1646672.trc
Sort options: exeela
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time IN seconds executing
elapsed  = elapsed time IN seconds executing
disk     = number of physical reads of buffers FROM disk
query    = number of buffers gotten FOR consistent READ
current  = number of buffers gotten IN current mode (usually FOR UPDATE)
rows     = number of rows processed BY the fetch OR execute call
********************************************************************************
 
WITH SR AS
(
  SELECT
         pns.ID_PENSIONNE
       , pns.BLOC_NOTE
       , pns.DATE_DECES
       , pns.DATE_NAISS
       , pns.ID_PENSIONNE_TMP
       , pns.ID_SERVICE
       , pns.NOM_MARITAL
       , pns.NOM_PATRONYME
       , pns.PRENOMS
    FROM PENSIONNE pns
   WHERE pns.ID_SERVICE = '059000'
     AND EXISTS (SELECT NULL
                   FROM SOUS_DOSSIER sdo
                        INNER JOIN DOCUMENT doc
                          ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER
                  WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                    AND doc.ID_TYPE_DOCUMENT = 10)
ORDER BY pns.ID_PENSIONNE ASC
)
SELECT ID_PENSIONNE
     , BLOC_NOTE
     , DATE_DECES
     , DATE_NAISS
     , ID_PENSIONNE_TMP
     , ID_SERVICE
     , NOM_MARITAL
     , NOM_PATRONYME
     , PRENOMS
  FROM SR
 WHERE ROWNUM <= 100
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.01       0.00          0          0          0           0
 
Misses IN library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 30
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       2        0.00          0.00
  SQL*Net message FROM client                     1        0.02          0.02
  db file sequential READ                     48515        0.00          0.31
 
 
 
********************************************************************************
 
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.01       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.01       0.00          0          0          0           0
 
Misses IN library cache during parse: 1
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       3        0.00          0.00
  SQL*Net message FROM client                     2        9.88          9.91
  db file sequential READ                     48515        0.00          0.31
 
 
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        0      0.00       0.00          0          0          0           0
Execute      0      0.00       0.00          0          0          0           0
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        0      0.00       0.00          0          0          0           0
 
Misses IN library cache during parse: 0
 
    2  user  SQL statements IN session.
    0  internal SQL statements IN session.
    2  SQL statements IN session.
********************************************************************************
Trace file: gm2011_ora_1646672.trc
Trace file compatibility: 10.01.00
Sort options: exeela
       1  session IN tracefile.
       2  user  SQL statements IN trace file.
       0  internal SQL statements IN trace file.
       2  SQL statements IN trace file.
       1  UNIQUE SQL statements IN trace file.
   48621  LINES IN trace file.
       0  elapsed seconds IN trace file.

mnitu · 20/12/2011, 15h47

Deux parse un execute ce n’est pas bon mais ça c’est une autre histoire.
Sinon ça va tellement vite sauf que apparemment ça n’a rien ramené (rows = 0).
Mais, il se peut aussi que la session n'a pas été fermée et que les statististique ne sont pas disponible.

jalaval · 21/12/2011, 09h42

Citation:

Envoyé par mnitu

Deux parse un execute ce n’est pas bon mais ça c’est une autre histoire.
Sinon ça va tellement vite sauf que apparemment ça n’a rien ramené (rows = 0).
Mais, il se peut aussi que la session n'a pas été fermée et que les statististique ne sont pas disponible.

OK voici la trace session fermée (c'est un peu long) :

Code :

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

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
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
 
 
TKPROF: Release 10.2.0.3.0 - Production ON Mer. Déc. 21 09:40:25 2011
 
Copyright (c) 1982, 2005, Oracle.  ALL rights reserved.
 
Trace file: /u02/admin/GM2011/udump/gm2011_ora_jla.trc
Sort options: exeela  
********************************************************************************
count    = number of times OCI procedure was executed
cpu      = cpu time IN seconds executing 
elapsed  = elapsed time IN seconds executing
disk     = number of physical reads of buffers FROM disk
query    = number of buffers gotten FOR consistent READ
current  = number of buffers gotten IN current mode (usually FOR UPDATE)
rows     = number of rows processed BY the fetch OR execute call
********************************************************************************
 
SELECT /*+ rule */ bucket, endpoint, col#, epvalue 
FROM
 histgrm$ WHERE obj#=:1 and intcol#=:2 and row#=:3 order by bucket
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     97      0.02       0.01          0          0          0           0
Fetch       97      0.02       0.09         17        395          0        1862
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      195      0.04       0.11         17        395          0        1862
 
Misses IN library cache during parse: 1
Misses IN library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 1)
 
Rows     Row Source Operation
-------  ---------------------------------------------------
     20  SORT ORDER BY (cr=4 pr=2 pw=0 time=12030 us)
     20   TABLE ACCESS CLUSTER HISTGRM$ (cr=4 pr=2 pw=0 time=11916 us)
      1    INDEX UNIQUE SCAN I_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=22 us)(object id 252)
 
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential READ                        17        0.00          0.07
********************************************************************************
 
SELECT /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, 
  sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, 
  spare1, spare2, avgcln 
FROM
 hist_head$ WHERE obj#=:1 and intcol#=:2
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     16      0.00       0.00          0          0          0           0
Fetch       16      0.00       0.01          2         48          0          16
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       33      0.00       0.02          2         48          0          16
 
Misses IN library cache during parse: 1
Misses IN library cache during execute: 1
Optimizer mode: RULE
Parsing user id: SYS   (recursive depth: 1)
 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID HIST_HEAD$ (cr=3 pr=1 pw=0 time=8853 us)
      1   INDEX RANGE SCAN I_HH_OBJ#_INTCOL# (cr=2 pr=0 pw=0 time=61 us)(object id 257)
 
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential READ                         2        0.00          0.01
********************************************************************************
 
SELECT o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,o.subname,
  o.dataobj#,o.flags 
FROM
 obj$ o WHERE o.obj#=:1
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute     10      0.01       0.00          0          0          0           0
Fetch       10      0.00       0.00          0         30          0          10
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total       21      0.01       0.00          0         30          0          10
 
Misses IN library cache during parse: 1
Misses IN library cache during execute: 1
Optimizer mode: CHOOSE
Parsing user id: SYS   (recursive depth: 1)
 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  TABLE ACCESS BY INDEX ROWID OBJ$ (cr=3 pr=0 pw=0 time=92 us)
      1   INDEX UNIQUE SCAN I_OBJ1 (cr=2 pr=0 pw=0 time=56 us)(object id 36)
 
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       1        0.00          0.00
  SQL*Net message FROM client                     1      119.34        119.34
********************************************************************************
 
begin :id := sys.dbms_transaction.local_transaction_id; end;
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           1
Fetch        0      0.00       0.00          0          0          0           0
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        2      0.00       0.00          0          0          0           1
 
Misses IN library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: 30  
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       1        0.00          0.00
  SQL*Net message FROM client                     1        0.02          0.02
********************************************************************************
 
SELECT 'x' 
FROM
 dual
 
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        1      0.00       0.00          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1      0.00       0.00          0          0          0           1
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        3      0.00       0.00          0          0          0           1
 
Misses IN library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 30  
 
Rows     Row Source Operation
-------  ---------------------------------------------------
      1  FAST DUAL  (cr=0 pr=0 pw=0 time=5 us)
 
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       1        0.00          0.00
  SQL*Net message FROM client                     1        0.02          0.02
********************************************************************************
 
WITH SR AS
(
  SELECT pns.ID_PENSIONNE
       , pns.BLOC_NOTE
       , pns.DATE_DECES
       , pns.DATE_NAISS
       , pns.ID_PENSIONNE_TMP
       , pns.ID_SERVICE
       , pns.NOM_MARITAL
       , pns.NOM_PATRONYME
       , pns.PRENOMS
    FROM PENSIONNE pns  
   WHERE pns.ID_SERVICE = '059000'
     AND EXISTS (SELECT NULL
                   FROM SOUS_DOSSIER sdo
                        INNER JOIN DOCUMENT doc
                          ON doc.ID_SOUS_DOSSIER = sdo.ID_SOUS_DOSSIER  
                  WHERE sdo.ID_PENSIONNE = pns.ID_PENSIONNE
                    AND doc.ID_TYPE_DOCUMENT = 10)
ORDER BY pns.ID_PENSIONNE ASC
)
SELECT ID_PENSIONNE
     , BLOC_NOTE
     , DATE_DECES
     , DATE_NAISS
     , ID_PENSIONNE_TMP
     , ID_SERVICE
     , NOM_MARITAL
     , NOM_PATRONYME
     , PRENOMS
  FROM SR
 WHERE ROWNUM <= 100
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        2      0.02       0.02          0          0          0           0
Execute      1      0.00       0.00          0          0          0           0
Fetch        1     41.30     244.17     542230    4183975          0         100
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        4     41.32     244.20     542230    4183975          0         100
 
Misses IN library cache during parse: 1
Optimizer mode: CHOOSE
Parsing user id: 30  
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       2        0.00          0.00
  SQL*Net message FROM client                     2       59.49         59.52
  db file sequential READ                    542230        0.17        209.16
  SQL*Net more DATA TO client                     5        0.00          0.00
 
 
 
********************************************************************************
 
OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.02       0.02          0          0          0           0
Execute      3      0.00       0.00          0          0          0           1
Fetch        2     41.30     244.17     542230    4183975          0         101
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9     41.32     244.20     542230    4183975          0         102
 
Misses IN library cache during parse: 2
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       6        0.00          0.00
  SQL*Net message FROM client                     6      119.34        179.59
  db file sequential READ                    542230        0.17        209.16
  SQL*Net more DATA TO client                     5        0.00          0.00
 
 
OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS
 
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        3      0.00       0.00          0          0          0           0
Execute    123      0.03       0.02          0          0          0           0
Fetch      123      0.02       0.10         19        473          0        1888
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total      249      0.05       0.13         19        473          0        1888
 
Misses IN library cache during parse: 3
Misses IN library cache during execute: 3
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  db file sequential READ                        19        0.00          0.09
 
    4  user  SQL statements IN session.
  123  internal SQL statements IN session.
  127  SQL statements IN session.
********************************************************************************
Trace file: /u02/admin/GM2011/udump/gm2011_ora_jla.trc
Trace file compatibility: 10.01.00
Sort options: exeela  
       1  session IN tracefile.
       4  user  SQL statements IN trace file.
     123  internal SQL statements IN trace file.
     127  SQL statements IN trace file.
       6  UNIQUE SQL statements IN trace file.
  545371  LINES IN trace file.
     303  elapsed seconds IN trace file.

mnitu · 21/12/2011, 17h47

Bref, on y voit la même chose :

Requêtes récursives induites par le parsing hard de la requête, mais sans importance.
Un nombre important de lecture physique
Un nombre important de lecture en mode consistent
Temps d’attente important dans la lecture en mode monobloc des données, très probablement d’un(des) index(es).

Peut-on avoir aussi le plan d’exécution pour cette requête ?

Mohamed.Houri · 21/12/2011, 19h19

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
call     count       cpu    elapsed       disk      query    current        rows
------- ------  -------- ---------- ---------- ---------- ----------  ----------
Parse        4      0.02       0.02          0          0          0           0
 
Execute      3      0.00       0.00          0          0          0           1
Fetch        2     41.30     244.17     542230    4183975          0         101
------- ------  -------- ---------- ---------- ---------- ----------  ----------
total        9     41.32     244.20     542230    4183975          0         102
 
Misses IN library cache during parse: 2
 
Elapsed times include waiting ON following events:
  Event waited ON                             Times   Max. Wait  Total Waited
  ----------------------------------------   Waited  ----------  ------------
  SQL*Net message TO client                       6        0.00          0.00
  SQL*Net message FROM client                     6      119.34        179.59
  db file sequential READ                    542230        0.17        209.16
  SQL*Net more DATA TO client                     5        0.00          0.00

Lorsqu'il existe une grande différence entre elapsed et cpu (224,20-41,32 = 182,88 secondes) comme c'est le cas ici, cela veut dire que vous avez passé du temps à attendre quelque chose. Ce quelque chose est représenté par db file sequential READ. Cet événement est souvent synonyme d'un accès via index. Ce qui, manifestement, est en contradiction avec le premier vrai plan d’exécution que vous avez présenté pour le id_type_document = 10 où la majeure partie du temps était consommée dans un FULL TABLE SCAN (synonyme de db file scattered READ) de la table document.

Code :

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

1
2
3
4
5
 
  ------------------------------------------------------------------------------------------------------------------
  | Id  | Operation                         | Name              | Starts | E-Rows | A-Rows |   A-Time   | Buffers | 
  ------------------------------------------------------------------------------------------------------------------
  |* 10 |       TABLE ACCESS FULL           | DOCUMENT          |      1 |   4187K|   4173K|00:00:12.52 |     460K

Votre requête s'est-elle mise à générer 4.183.975 en utilisant un INDEX sur la table DOCUMENT? ce qui expliquerait peut-être la différence dans le temps de réponse contenue dans la trace(244,20) et celui fournit dans le premier vrai plan d’exécution (12,52 secondes pour le FULL TABLE SCAN et 43 secondes en tout)?

Dommage que le plan d’exécution n'a pas été inclus dans cette trace.

Si vous n'êtes pas satisfait par le temps de réponse il faudra faire une optimisation manuelle comme l'a fait Jonathan Lewis dans un contexte qui ressemble un peu au votre mais où pour lui c'était l'opération ORDER BY qui posait le plus problème ce qui n'est pas votre cas ici.

http://jonathanlewis.wordpress.com/2...l-optimisation

En rédigeant ces quelques lignes j'ai revu votre requête et il me semble que la jointure externe suivante

Code :

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

1
2
3
4
 
LEFT OUTER JOIN
            DOCUMENT documentco2_ 
                ON sousdossie1_.ID_SOUS_DOSSIER=documentco2_.ID_SOUS_DOSSIER

doit être remplacée par une simple jointure à cause de

Code :

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

1
2
 
AND documentco2_.ID_TYPE_DOCUMENT='10'

skuatamad · 21/12/2011, 20h01

Juste pour te donner quelques liens qui peuvent t'intéresser :
db file sequential read

Et sur asktom, pour quelques pistes de reflexions :
Wait event: DB file sequential read

Mohamed, Il a utilisé la requête de Waldar, il est donc impossible de comparer le tkprof avec les précédents plans.
jalaval, normalement le tkprof devrait contenir le plan réel dans la section Row Source Operation, sinon regénère un plan pour cette requête, par contre on a l'air loin des 25s dont tu parlais.

16/12/2011, 16h12	#26
Mohamed.Houri Membre chevronné Mohamed Houri Inscription : mars 2010 Messages : 402 Détails du profil Informations personnelles : Nom : Mohamed Houri Localisation : France Informations forums : Inscription : mars 2010 Messages : 402 Points : 797 Points : 797	Si tant est que cela soit possible, comment être sûr dans ce cas que les statistiques sont à jour???? Je ne pense pas que ce que vous proposez soit possible. Il faudrait plutôt se concentrer sur l'amélioration de votre requête. J'ai une question quand même : Est-ce que le client se plaint de la performance parce qu'il s'est habitué à voir cette requête s'exécuter rapidement ou bien c'est du premier coup qu'il s'est plaint de la performance? __________________ Bien Respectueusement www.hourim.wordpress.com "Ce qui se conçoit bien s'énonce clairement"
	00

19/12/2011, 19h34	#32
pacmann Membre Expert Pacman Pacman Business analyst Inscription : juin 2004 Messages : 1 424 Détails du profil Informations personnelles : Nom : Pacman Pacman Âge : 32 Localisation : France, Paris (Île de France) Informations professionnelles : Activité : Business analyst Secteur : Finance Informations forums : Inscription : juin 2004 Messages : 1 424 Points : 2 433 Points : 2 433	Salut, Je suis bien d'accord avec toi Waldar. Cela dit ce n'est pas forcément le besoin qui est mal exprimé, ça peut très bien être le modèle ou le "process". Finalement, on voit souvent ce genre de problème : ton modèle est totalement normalisé, et tes critères de recherche (sans dépendances) sont éparpillés. T'es obligé de faire une VM comme le suggère Skuat. La seule question qui reste c'est : est-il rationnel de faire une recherche sur la possession d'un type de document ? Quel est la fréquence d'une telle recherche ? - Si c'est un cas d'exception, 50 secondes ne sont vraiment pas choquantes. - Si c'est le quotidien du chargé, il faut faire une VM, et surtout se demander pourquoi on doit sortir en interactif la liste des gens qui ont eu un certain type de document... __________________ (c'est ma photo) Paku, Paku ! Pour les jeunes incultes : non, je ne suis pas un pokémon... Le pacblog : http://pacmann.over-blog.com/
	00

21/12/2011, 17h47	#38
mnitu Expert Confirmé Sénior Marius Nitu Ingénieur développement logiciels Inscription : octobre 2007 Messages : 4 104 Détails du profil Informations personnelles : Nom : Marius Nitu Localisation : France, Marne (Champagne Ardenne) Informations professionnelles : Activité : Ingénieur développement logiciels Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : octobre 2007 Messages : 4 104 Points : 7 994 Points : 7 994	Bref, on y voit la même chose : Requêtes récursives induites par le parsing hard de la requête, mais sans importance. Un nombre important de lecture physique Un nombre important de lecture en mode consistent Temps d’attente important dans la lecture en mode monobloc des données, très probablement d’un(des) index(es). Peut-on avoir aussi le plan d’exécution pour cette requête ?
	00

16/12/2011, 14h08	#22
Rams7s Membre chevronné François Inscription : février 2010 Messages : 394 Détails du profil Informations personnelles : Nom : François Informations forums : Inscription : février 2010 Messages : 394 Points : 716 Points : 716	Perso, je tenterai bien un index sur documents(id_type_document,id_sous_dossier) au lieu de l'index sur documents(id_type_document). Pour le requetes ou le numero de type_document est peu present, on aurait le meme effet. Et pour les requetes genre celle ou vous avec id_type_document=10 qui renvoie tout plein de resultats, ca permettrait peut-etre d'utiliser l'index, en un "fast full-index scan" vu que toutes les infos seraient dedans. Parce que la concretement, il peut pas l'utiliser pour id_type_document=10. Edit:Et d'ailleurs, tant qu'on y est: SOUS_DOSSIER(ID_PENSIONNE,ID_SOUS_DOSSIER )Mais pour l'ordre des colonnes, la je suis pas tres convaincu. Mais bon, visiblement c'est pas ca qui prends du temps, ce qui est marrant d'ailleurs...
	00

16/12/2011, 14h39	#23
jalaval Invité de passage jean LAVAL Chef de projet NTIC Inscription : décembre 2011 Messages : 15 Détails du profil Informations personnelles : Nom : jean LAVAL Localisation : France, Somme (Picardie) Informations professionnelles : Activité : Chef de projet NTIC Secteur : Administration - Collectivité locale Informations forums : Inscription : décembre 2011 Messages : 15 Points : 1 Points : 1	Merci pour cette piste. Cependant, j'ai créé l'index documents(id_type_document,id_sous_dossier), mais cela ne change rien au plan d’exécution : ce nouvel index n'est pas utilisé.
	00

16/12/2011, 16h04	#25
jalaval Invité de passage jean LAVAL Chef de projet NTIC Inscription : décembre 2011 Messages : 15 Détails du profil Informations personnelles : Nom : jean LAVAL Localisation : France, Somme (Picardie) Informations professionnelles : Activité : Chef de projet NTIC Secteur : Administration - Collectivité locale Informations forums : Inscription : décembre 2011 Messages : 15 Points : 1 Points : 1	Je reformule ma question : Est il possible dans un programme (java ou autre) de connaitre le nombre de lignes qu'une requête va ramener, mais sans exécuter la requête (ie en se basant sur les statistiques) ?
	00

16/12/2011, 16h19	#27
jalaval Invité de passage jean LAVAL Chef de projet NTIC Inscription : décembre 2011 Messages : 15 Détails du profil Informations personnelles : Nom : jean LAVAL Localisation : France, Somme (Picardie) Informations professionnelles : Activité : Chef de projet NTIC Secteur : Administration - Collectivité locale Informations forums : Inscription : décembre 2011 Messages : 15 Points : 1 Points : 1	Le client est en phase de recette de cette application, et considère comme une anomalie les temps de réponse de ce cas d'utilisation. Il accepterait que le système renvoie un message à l'utilisateur lui précisant que le résultat de sa recherche va dépasser les 100 réponses et lui demandant d'affiner ses critères de recherches (sans que la recherche soit effectivement faite). En ce qui concerne la validité des statistiques, ne sont elles pas maintenues à jour en permanence par Oracle ?
	00

20/12/2011, 15h47	#36
mnitu Expert Confirmé Sénior Marius Nitu Ingénieur développement logiciels Inscription : octobre 2007 Messages : 4 104 Détails du profil Informations personnelles : Nom : Marius Nitu Localisation : France, Marne (Champagne Ardenne) Informations professionnelles : Activité : Ingénieur développement logiciels Secteur : High Tech - Éditeur de logiciels Informations forums : Inscription : octobre 2007 Messages : 4 104 Points : 7 994 Points : 7 994	Deux parse un execute ce n’est pas bon mais ça c’est une autre histoire. Sinon ça va tellement vite sauf que apparemment ça n’a rien ramené (rows = 0). Mais, il se peut aussi que la session n'a pas été fermée et que les statististique ne sont pas disponible.
	00

21/12/2011, 20h01	#40
skuatamad Expert Confirmé Inscription : août 2008 Messages : 1 690 Détails du profil Informations forums : Inscription : août 2008 Messages : 1 690 Points : 2 813 Points : 2 813	Juste pour te donner quelques liens qui peuvent t'intéresser : db file sequential read Et sur asktom, pour quelques pistes de reflexions : Wait event: DB file sequential read Mohamed, Il a utilisé la requête de Waldar, il est donc impossible de comparer le tkprof avec les précédents plans. jalaval, normalement le tkprof devrait contenir le plan réel dans la section Row Source Operation, sinon regénère un plan pour cette requête, par contre on a l'air loin des 25s dont tu parlais.
	10

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email