Discussion :

[Ikebukuro]

Bonjour,

En affichant un plan d'exécution, Oracle ne renseigne la colonne TIME qu'avec une précision au niveau de la seconde.

Code :

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

1
2
3
4
5
6
7
8
------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name           | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                |     1 |    65 |     5   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| PC_RENDEMENT   |     1 |    65 |     5   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN                  | PC_RENDEMENT_1 |     5 |       |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------------------------------

Néanmoins, avec le hint GATHER_PLAN_STATISTICS, on descend au dixième de seconde.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
select /*+ GATHER_PLAN_STATISTICS */ debut, fin from T1 where ((l_support = '205') and ((edn <= 79) and ((dn <= 79) and (((edx > 64) or (dx > 7)) and (xa > 796)))));

SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------
| Id  | Operation                           | Name           | Starts | E-Rows | A-Rows |   A-Time   | Buffers |
----------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |                |      1 |        |      1 |00:00:00.01 |       5 |
|*  1 |  TABLE ACCESS BY INDEX ROWID BATCHED| PC_RENDEMENT   |      1 |      1 |      1 |00:00:00.01 |       5 |
|*  2 |   INDEX RANGE SCAN                  | PC_RENDEMENT_1 |      1 |      5 |      5 |00:00:00.01 |       3 |
----------------------------------------------------------------------------------------------------------------

Est-il possible d'aller facilement plus bas, au niveau de la milli-seconde par exemple? Par facilement j'entends sans passer par une trace 10053...
Mon objectif est de tuner la requête et comme elle est hyper simple et s'exécute très vite, il me faut la valeur la plus précise possible.
Précision : elle s'exécute très vite MAIS le client la lance 50 000 fois dans un batch et le batch prend presque 5 heures, donc on veut tuner celle-ci.

[EDIT]
Je vois que dans V$SQL on a des temps en micro-secondes
Je vais tester ça...


Merci pour vos idées.

[Waldar]

Pour optimiser une requête qui va hyper vite, on regarde sa consommation I/O, CPU et mémoire, pas vraiment le temps consommé.
Autotrace devrait vous fournir ces informations (j'ai un doute sur la mémoire cela dit).

[Pomalaix]

A vrai dire, vous avez déjà des informations au centième de seconde dans ce que vous montrez !
Dans v$sql_plan_statistics_all, la colonne last_elapsed_time fournit les temps en microsecondes de chaque étape du plan pour la dernière exécution de la requête.
Si le détail de chaque étape ne vous intéresse pas, vous pouvez filtrer sur "operation='SELECT STATEMENT'" pour avoir le temps du SELECT total.

Mais de toute façon, travailler au niveau des centièmes de secondes est déjà sans intérêt, car d'une exécution à l'autre la fluctuation peut être importante, sans qu'il n'y ait de raison particulière. On risque donc surtout de tirer de mauvaises conclusions !
Par exemple, si la requête, après reformulation, passe de 0,2 à 0,1 seconde, on ne peut absolument rien en conclure, car on est en plein dans la marge de fluctuation.

Pour des requêtes dont la durée d'exécution est inférieure à la seconde, il est préférable de faire tourner la requête plusieurs dizaines ou centaines de fois pour atteindre des temps d'au moins 10 secondes.
On pourra alors déterminer plus fiablement que telle modification a amélioré ou dégradé les temps dans telle proportion.

De plus, si on s'intéresse juste au temps d'exécution global (et non de chaque étape du plan), un bon vieux SET TIMING ON dans SQL*Plus fera l'affaire, puisqu'il a une résolution au centième de seconde.

[Ikebukuro]

Un gros merci à vous deux, vos conseils sont excellents

[pachot]

Bonjour,
Une solution est de lancer la requête 1000 fois et de regarded 'ALLSTATS' sans le 'LAST' pour voir le temps cumulé sur toutes les exécutions du curseur. Avec au besoin un flusg shared pool avant pour être sûr de partir à zéro. Mais le meilleur tuning serait d'éviter de lancer 50000 fois. Beaucoup de temps est passé en latence réseau et switch de contexte (et sur Intel ça va être pire avec les fixes des dernières vulnérabilités )
Cordialement
Franck.