Discussion :

[rockley]

Bonjour,

J'aimerais mieux comprendre le fonctionnement d'oracle au niveau des performances.
Ma question est simple, j'ai la requête ci-dessous :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT 
    *
FROM (
    select
        a.*,
        ROW_NUMBER() OVER (ORDER BY a.ID DESC) rn
    from Table a
    where       
        a.STATUS IN('1', '2', '5', '6', '8')
) result
WHERE rn > 0 and rn <= 15

Cost (%CPU) = 15 (100)

A présent je change juste un petit truc dans ma requête :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT 
    count(*)
FROM (
    select
        a.*,
        ROW_NUMBER() OVER (ORDER BY a.ID DESC) rn
    from Table a
    where       
        a.STATUS IN('1', '2', '5', '6', '8')
) result
WHERE rn > 0 and rn <= 15

Cost (%CPU) = 11585 (1)

Quelqu'un pourrait m'expliquer ce que oracle fabrique pour prendre 1000 fois plus de CPU pour un simple count et pour afficher 15 ?

Merci d'avance pour votre aide

[Ikebukuro]

Si tu veux savoir ce que fabrique Oracle quand il exécute une requête, il faut récupérer son plan d'exécution.
Vu que dans tes requêtes il n'y a pas de bind variables, la solution la plus simple est d'afficher le plan d'exécution estimé par l'optimiseur.
Pour cela, fait

Code :

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

1
2
3
SET AUTOTRACE ON;
lancement de ta requête
SET AUTOTRACE OFF;

Une fois cela fait, post ici le résultat. Si ce n'est pas plus clair, il faudra afficher le vrai plan d'exécution, pas celui estimé mais c'est un peut plus ardu : un tuto ici
https://sqlmaria.com/2017/08/08/usin...ecution-plans/

[skuatamad]

Par ailleurs le COST n'est pas une métrique comparable entre 2 requêtes :
Consider Cost or Time - trying to compare the COST of two queries

[vanagreg]

Bonjour,

Déjà il faudrait donner la version exacte concernée!
De plus, il faudrait donner les plans d'exécution complets faits en SQL*Plus.

[Ikebukuro]

Par ailleurs le COST n'est pas une métrique comparable entre 2 requêtes :
Consider Cost or Time - trying to compare the COST of two queries

Tu as parfaitement raison, je ne sais pas pourquoi il s'est focalisé sur le COST mais celui-ci ne sert qu'à comparer, pour un même sql_id, N plans entre eux et à choisir le moins élevé.

[rockley]

Bonjour à tous,

Merci pour vos retours.
Je me suis focalisé sur le cost car je viens d'un monde DB2 à la base et que l'explain n'est pas exactement la même chose.

Donc si je fais un

Code :

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

1
2
 
select /*+ GATHER_PLAN_STATISTICS */

Puis :

Code :

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

1
2
 
SELECT * FROM TABLE(DBMS_XPLAN.display_cursor(format=>'ALLSTATS LAST +cost +bytes +outline'));

J'obtiens les vrais résultats d'exécution de la requête ?
Et si oui que je dois prend en compte ? Le A-Time ?

[Ikebukuro]

Oui, tu auras le vrai plan d'exécution avec cette commande.
Et le A-TIME (Actual time) est mieux que le E-TIME (Estimated time) même si certains te disent qu'il n'est aps fiable à 100% : http://www.dba-oracle.com/t_a_time_execution_plan.htm
Sinon sous SQL*Plus tu peux faire un
set timing on
avant de lancer le SELECT pour afficher le temps total passé sur ton SELECT.

[rockley]

Un grand merci à tous pour votre aide.
Le temps d'exécution du count(*) est en fait très acceptable

Je me suis fait avoir par le COST sans savoir que c'était juste une estimation.