Question Time Plan

Version imprimable

Question Time Plan

Bonjour,

Je cherche à comprendre le rapport entre ELAPSED_TIME remonté par cette requête et Time remonté dans le Plan ? et entre BUFFER_GETS (Requête) et consistent gets Plan) ?

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
SQL> select to_char(LAST_ACTIVE_TIME, 'DD/MM/YYYY HH24:MI:SS'), EXECUTIONS, ROWS_PROCESSED, CPU_TIME, ELAPSED_TIME, BUFFER_GETS from V$SQLSTATS where SQL_ID = 'gmakm8zzgh3ta';
TO_CHAR(LAST_ACTIVE EXECUTIONS ROWS_PROCESSED   CPU_TIME ELAPSED_TIME BUFFER_GETS
------------------- ---------- -------------- ---------- ------------ -----------
25/03/2021 17:20:49          1          20000      78125       129684        1778
Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 3582063246
----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        | 20000 |  2363K|   102   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2363K|   102   (1)| 00:00:01 |
----------------------------------------------------------------------------
Statistiques
----------------------------------------------------------
          1  recursive calls
          4  db block gets
       1670  consistent gets
          0  physical reads
          0  redo size
    1216454  bytes sent via SQL*Net to client
      15271  bytes received via SQL*Net from client
       1335  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
      20000  rows processed

Merci.

A+

25/03/2021, 19h06
Ikebukuro

Tiens, tu crées tes tables avec le même nom que moi : ZZTEST :D

Attention, V$SQLSTATS est une vue agrégée, pas détaillée donc ici tu as de la chance, EXECUTIONS vaut 1 mais si ça valait 10, tu ne pourrais pas diviser chaque donnée par 10 car tu aurais uniquement une moyenne.
Dans le plan il manque la colonne "consistent gets".
La colonne ELAPSED_TIME de V$SQLSTATS est en micro secondes soit ici 0,1 seconde. Comme dans ton plan d'exécution on a pas les 10ème de secondes, Oracle arrondit à 1 seconde.

Comment as-tu obtenu ton plan d'exécution? C'est quoi l'ordre SELECT exécuté?

Bonjour,

Je me suis servi, j'ai utilisé ta table (créée à base de DBA_OBJECTS) pour faire mon p'tit TP perso :D Merci de ton article bien fait :ccool:

J'ai fait un select * puis mon plan généré avec :

Code:

set autotrace on explain

J'ai refait un test avec :

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
EXPLAIN PLAN FOR select * from zztest;
Plan hash value: 3582063246
 
----------------------------------------------------------------------------
| Id  | Operation         | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |        | 20000 |  2363K|   102   (1)| 00:00:01 |
|   1 |  TABLE ACCESS FULL| ZZTEST | 20000 |  2363K|   102   (1)| 00:00:01 |
----------------------------------------------------------------------------
 
8 lignes sÚlectionnÚes.
 
 
Plan d'exÚcution
----------------------------------------------------------
Plan hash value: 2137789089
 
---------------------------------------------------------------------------------------------
| Id  | Operation                         | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                  |         |  8168 | 16336 |    29   (0)| 00:00:01 |
|   1 |  COLLECTION ITERATOR PICKLER FETCH| DISPLAY |  8168 | 16336 |    29   (0)| 00:00:01 |
---------------------------------------------------------------------------------------------
 
 
Statistiques
----------------------------------------------------------
         14  recursive calls
          0  db block gets
         12  consistent gets
          0  physical reads
        120  redo size
       1131  bytes sent via SQL*Net to client
        608  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          1  sorts (memory)
          0  sorts (disk)
          8  rows processed
 
SQL>

Il y a 2 plan: Plan hash value: 3582063246 et Plan hash value: 2137789089 ?

MERCI encore.

A+

26/03/2021, 11h03
Ikebukuro

Si tu as fais exactement le même SELECT, je ne vois pas pourquoi il y aurait deux plan hash value différents; en plus il n'y a pas de bind variables dans le SELECT donc c'est un pb en moins.

Tu as bien fais

Code:

set autotrace on explain

avant de lancer le SELECT?

Et c'est quoi le plan d'exécution avec le hash value de 2137789089?

Re et Merci.

Je suis un peu perdu ! j'ai ça pour ce code plan

Code:

1
2
3
4
5
6
7
SQL> select distinct(sql_id) from v$sql_plan where plan_hash_value='2137789089';
 
SQL_ID
-------------
bsvpwnht1m9bm
3s1hh8cvfan6w
ff5spha9pjuyu

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
SQL> select sql_text from v$sql
  2  where sql_id ='bsvpwnht1m9bm';
 
SQL_TEXT
--------------------------------------------------------------------------------------------------------------------------------------------
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE', :1))
 
SQL> select sql_text from v$sql
  2  where sql_id ='ff5spha9pjuyu';
 
SQL_TEXT
----------------------------------------------------------------------------------------------------------------------------------------------
select * from table(dbms_xplan.display)

Je n'ai pas compris le fait que sql_id/hash_value peuvent avoir plusieurs PLAN_HASH_VALUE !

MERCI

A+

Un SQL_ID peut avoir plusieurs plan hash value et chacun est le meilleur, selon le contexte.
Par exemple

Code:

SELECT * FROM ZZTEST WHERE NAME = :NOM;

Si :NOM vaut "DUPONT" et que ce nom représente 90% de la table ZZTEST, tu auras un plan d'exécution avec un FULL TABLE SCAN.
Si :NOM vaut "ZARAMO" et que ce nom représente 1% de la table ZZTEST, tu auras un plan d'exécution avec utilisation d'un index.

Un plan d'exécution peut être associé à plusieurs SQL_ID.
Par exemple si la majorité des DUPONT habite PARIS, les SELECTs suivants donnent deux SQL_ID différents mais le même plan d'exécution.
Code:

1 2 SELECT * FROM ZZTEST WHERE NOM = 'DUPONT'; SELECT * FROM ZZTEST WHERE NOM = 'DUPONT' AND VILLE = 'PARIS';
Quand tu as généré le plan ci-dessous, ce n'est pas lié à un SELECT applicatif. C'est certainement parce que tu as fais un AUTOTRACE après ton SELECT car les SELECTs avec les id bsvpwnht1m9bm, 3s1hh8cvfan6w et ff5spha9pjuyu sont des SELECTs internes à Oracle, liés à ta demande d'afficher les plans.
Code:

1 2 3 4 5 6 7 8 9 10 Plan d'exÚcution ---------------------------------------------------------- Plan hash value: 2137789089 --------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | --------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 8168 | 16336 | 29 (0)| 00:00:01 | | 1 | COLLECTION ITERATOR PICKLER FETCH| DISPLAY | 8168 | 16336 | 29 (0)| 00:00:01 | ---------------------------------------------------------------------------------------------
Donc rappel : l'ordre est important.

Code:

EXPLAIN PLAN FOR SELECT***

puis utiliser dbms_xplan.display (pas dbms_xplan.display_cursor).
Ou bien
Code:

1 2 SET AUTOTRACE ON SELECT***
puis utiliser dbms_xplan.display (pas dbms_xplan.display_cursor).

Merci bcp pour ces précieuses infos :ccool:

Une dernière:

Code:

1
2
3
4
5
6
7
8
9
10
SQL_ID           DB_TIME    PCTLOAD
------------- ---------- ----------
b6usrg82hwsa3         23      11,92
a01hp0psv0rrh         14       7,25
                      12       6,22
6h1ysp5jm8h8m         10       5,18
1j6tnz8fcm4c3          8       4,15
.................
..........
.....

J'ai cherché mais je n'ai pas trouvé à qui correspond exactement PCTLOAD ?

MERCI.

A+

26/03/2021, 21h42
Ikebukuro

Il faut nous donner l'ordre SQL qui génère ce résultat; j'ai l'impression que PCTLOAD est un alias sur une opération mathématique.
27/03/2021, 11h42
agdid04

Bonjour à ts, je me suis posé la même question.

A+

Bonjour et Merci de retour.

Il s'agit des sessions non BACKGROUND

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SQL> select sql_id
  2  , count(*) DB_TIME
  3  , round(count(*)*100/sum(count(*))
  4  over (),2) pctload
  5  from v$active_session_history
  6  where session_type <> 'BACKGROUND'
  7  group by sql_id
  8  order by count(*) desc;
 
SQL_ID           DB_TIME    PCTLOAD
------------- ---------- ----------
b6usrg82hwsa3         23      11,92
a01hp0psv0rrh         14       7,25
                      12       6,22
6h1ysp5jm8h8m         10       5,18
1j6tnz8fcm4c3          8       4,15
92pjdkx1t1cxk          6       3,11
0t4xjrm1kyybt          6       3,11
572fbaj0fdw2b          6       3,11
3xjw1ncw5vh27          5       2,59

MERCI.

A+

27/03/2021, 15h30
Ikebukuro

C'est bien ce que je disais, c'est un alias et visiblement ce nombre représente le pourcentage de charge de chaque ordre SQL.
29/03/2021, 10h34
dari68

Merci bcp :ccool::ccool::ccool:

Avant de clore cette conversation, d'après votre expérience quelles sont les autres vues à avoir dans sa boîte à outils Perf/diagnostic (y en beaucoup) mais les plus pertinentes ?

MERCI.

A+
29/03/2021, 12h47
Ikebukuro

Toutes les vues AWR : DBA_HIST_*** mais il faut avoir le diagnostique pack,
V$ACTIVE_SESSION_HISTORY,
les vues V$SQL***
toutes les vues DBA***STAT*** et V$***STAT*
29/03/2021, 12h59
dari68

MERCI BCP.

A+