Même COST pour un ordre SQL déjà en mémoire?
Bonjour,
J'ai exécuté les trois ordres SQL suivants pour voir s'il y avait en terme de coût une différence entre COUNT(*) ou COUNT(1) ou COUNT(autre_chose).
Le nombre renvoyé est le même --> normal.
Pour la requête 1, le coût est de 10998 pour la lecture physique de 10991 blocs. Temps de traitement rapide : 5 secondes.
Pour les requêtes 2 et 3 le temps de réponse était immédiat --> normal car même si je change le paramètre de COUNT, je pense qu'Oracle récupère le résultat de l'ordre précédent en ayant mis en variable le paramètre (création de bind variables?) et donc il voit que l'ordre est le même.
Là où je suis surpris c'est le coût des requêtes 2 et 3 : 10098 alors qu'il n'y a AUCUNE lecture physique ou logique ! Si Oracle a repris le résultat en mémoire, c'est rien comme action... je ne sais même pas si le résultat 4674233 est stocké dans un bloc (a priori non) ou dans une zone mémoire ou une variable mais réafficher ce nombre n'a demandé aucun travail donc j'en déduis que le plan d'exécution et le coût de l'ordre SQL est faux? J'ai lu des choses sur le BIND VARIABLE PEEKING mais ça n'explique pas pourquoi le coût ne change pas.
Quelqu'un pourrait m'expliquer ce problème? Par avance merci.
Code exécuté sous TOAD 9.7.2.5.
Code:
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
| select count(*) from CVBN_CURRENT_VALDATE_SECBAL;
COUNT(*)
----------
4674233
1 row selected.
Execution Plan
----------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=10998 Card=1)
1 SORT AGGREGATE (Card=1)
2 1 INDEX FULL SCAN ISI$OWNER.IDX_CVBN_CVB_CBS_ID (Cost=10998 Card=4 M)
Statistics
----------------------------------------------------------
0 user rollbacks
0 global enqueue gets async
10991 physical read total IO requests
0 physical read partial requests
0 DBWR lru scans
0 rollback changes - undo records applied
0 transaction rollbacks
0 immediate (CURRENT) block cleanout applications
0 active txn count during cleanout
0 cleanout - number of ktugct calls
1 rows processed
select count(sysdate) from CVBN_CURRENT_VALDATE_SECBAL;
COUNT(SYSDATE)
--------------
4674233
1 row selected.
Execution Plan
----------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=10998 Card=1)
1 SORT AGGREGATE (Card=1)
2 1 INDEX FULL SCAN ISI$OWNER.IDX_CVBN_CVB_CBS_ID (Cost=10998 Card=4 M)
Statistics
----------------------------------------------------------
0 user rollbacks
0 global enqueue gets async
0 physical read total IO requests
0 physical read partial requests
0 DBWR lru scans
0 rollback changes - undo records applied
0 transaction rollbacks
0 immediate (CURRENT) block cleanout applications
0 active txn count during cleanout
0 cleanout - number of ktugct calls
1 rows processed
select count(1) from CVBN_CURRENT_VALDATE_SECBAL;
COUNT(1)
----------
4674233
1 row selected.
Execution Plan
----------------------------------------------------------
SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=10998 Card=1)
1 SORT AGGREGATE (Card=1)
2 1 INDEX FULL SCAN ISI$OWNER.IDX_CVBN_CVB_CBS_ID (Cost=10998 Card=4 M)
Statistics
----------------------------------------------------------
0 user rollbacks
0 global enqueue gets async
0 physical read total IO requests
0 physical read partial requests
0 DBWR lru scans
0 rollback changes - undo records applied
0 transaction rollbacks
0 immediate (CURRENT) block cleanout applications
0 active txn count during cleanout
0 cleanout - number of ktugct calls
1 rows processed |
