IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

Même COST pour un ordre SQL déjà en mémoire? [11gR2]


Sujet :

Administration Oracle

  1. #1
    Membre émérite
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2013
    Messages
    1 992
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 992
    Points : 2 498
    Points
    2 498
    Par défaut 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 : 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
    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
    DBA Oracle
    Rédacteur du blog : dbaoraclesql.canalblog.com

  2. #2
    Rédacteur

    Homme Profil pro
    Consultant / formateur Oracle et SQL Server
    Inscrit en
    Décembre 2002
    Messages
    3 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Consultant / formateur Oracle et SQL Server

    Informations forums :
    Inscription : Décembre 2002
    Messages : 3 460
    Points : 8 073
    Points
    8 073
    Par défaut
    C'est tout simple.
    Le plan obtenu de cette manière fournit un coût théorique, en supposant qu'il faut tout aller lire sur disque.
    Les statistiques, de leur côté, renseignent sur l'exécution réelle qui vient d'avoir lieu.

    Par ailleurs, sauf utilisation explicite du cache de résultat, Oracle ne mémorise pas le résultat d'une requête.
    Vous avez manifestement profité du fait que les blocs utiles ont été conservés en cache à l'issue de la première requête, d'où cette sensation d'immédiateté du résultat.

    Vous dites qu'il n'y a ni lecture physique ni logique. Je suis d'accord au niveau physique, mais vos statistiques ne montrent rien des lectures logiques, qui ne sont bien évidemment pas inexistantes !

    Je vous suggère plutôt d'utiliser SQL*Plus, avec SET AUTOTRACE ON et SET TIMING ON.
    Consultant / formateur Oracle indépendant
    Certifié OCP 12c, 11g, 10g ; sécurité 11g

    Ma dernière formation Oracle 19c publiée sur Linkedin : https://fr.linkedin.com/learning/oracle-19c-l-administration

  3. #3
    Membre émérite
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Avril 2013
    Messages
    1 992
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Avril 2013
    Messages : 1 992
    Points : 2 498
    Points
    2 498
    Par défaut
    Salut Pomalaix,

    J'avais déjà constaté cette différence entre Toad et SQL*Plus sur les libellés des stats avec Autotrace. Je préfère ceux de SQL*Plus plus parlant : sous Toad il y a deux lignes pour les lectures physiques et 0 pour les lectures logiques alors que sous SQL*Plus on a 2 lignes pour les lectures logiques et une pour les lectures physiques... bizarre cette différence.

    Quand on fait un Autotrace, derrière Oracle fait un Explain plan je crois? Donc c'est pourquoi le plan d'exécution est comme tu dis un plan d'exécution théorique?
    DBA Oracle
    Rédacteur du blog : dbaoraclesql.canalblog.com

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. Réponses: 9
    Dernier message: 19/02/2009, 15h39
  2. Réponses: 3
    Dernier message: 17/02/2009, 14h43
  3. presentation d'un ordre SQL
    Par waffle200 dans le forum Langage SQL
    Réponses: 2
    Dernier message: 02/10/2003, 16h17
  4. Quel outil choisir pour un développement SQL-Server ?
    Par Mouse dans le forum Débats sur le développement - Le Best Of
    Réponses: 23
    Dernier message: 12/08/2003, 07h23
  5. Cours, tutoriels, logiciels, F.A.Q,... pour le langage SQL
    Par Marc Lussac dans le forum Langage SQL
    Réponses: 0
    Dernier message: 04/04/2002, 11h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo