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 :

statpack : requetes les plus consommatrices


Sujet :

Administration Oracle

  1. #1
    Membre régulier
    Inscrit en
    Août 2009
    Messages
    107
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : Août 2009
    Messages : 107
    Points : 124
    Points
    124
    Par défaut statpack : requetes les plus consommatrices
    Bonjour,

    Il y a une chose qui m'échappe avec statpack : sur une base 9.2.0.8 il y a un snapshot effectué automatiquement toutes les 30 minutes. Lorsque que je fais un rapport entre 08h et 08h30, j'ai une requête qui apparait en tête dans le classement des requêtes par lecture disque (200 000 blocs en lecture). Lorsque je fais un rapport entre 08h00 et 09h00, cette requête n'apparait plus alors qu'elle devrait être en deuxième position au vu de nombre de blocs lus !

    Est ce que quelqu'un a une idée de l'origine de ce comportement ?
    merci de votre aide

  2. #2
    Membre averti
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    750
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 750
    Points : 341
    Points
    341
    Par défaut
    envoie le début de tes 2 rapport statspack

  3. #3
    Membre régulier
    Inscrit en
    Août 2009
    Messages
    107
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : Août 2009
    Messages : 107
    Points : 124
    Points
    124
    Par défaut en tête stat pack
    1. Pour le premier :

    • En tete :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
                --------- ------------------ -------- --------- -------------------
    Begin Snap:     18319 06-Oct-09 19:00:01       26       6.2
      End Snap:     18321 06-Oct-09 20:00:02       24       5.3
       Elapsed:               60.02 (mins)
    • Physical reads

    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
     
                                                         CPU      Elapsd
     Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
    --------------- ------------ -------------- ------ -------- --------- ----------
            224,426       81,354            2.8    7.7    92.60   1070.41 1063516884
    Module: /logi/hraccess50/zf9/bin/RTSDGN@nyplsacc (TNS V1
    select NUDOSS  ,SOCDOS  ,NULIGN  ,TO_CHAR(DATDEB,'YYYY-MM-DD')
    ,MOTIFA  ,TO_CHAR(DATFIN,'YYYY-MM-DD')  ,TEMDEB  ,TEMFIN  ,GESTI
    O  ,PROLON  ,UNITE1  ,TEMTR1  ,UNITE2  ,TEMTR2  ,ELEMAT  ,TO_CHA
    R(DATUT1,'YYYY-MM-DD')  ,TO_CHAR(DATUT2,'YYYY-MM-DD')  ,SUITUT
    ,TESELE  ,HRSDEB  ,HRSFIN  ,NBHEUR  ,POURCE  ,IDLVSR  ,IDRTST  ,
     
             82,688       70,663            1.2    2.8    34.01   3492.20 2722121910
    Module: /logi/hraccess50/zf9/bin/RTSDGN@nyplsacc (TNS V1
    insert into ZYWV(NUDOSS,SOCDOS,NULIGN,OUTILM,DATDER,PRODEF,CDINF
    O,DATDEB,DATCPM,DATFIN) values (:b1,:b2,:b3,:b4,TO_DATE(:b5,'YYY
    Y-MM-DD'),:b6,:b7,TO_DATE(:b8,'YYYY-MM-DD'),TO_DATE(:b9,'YYYY-MM
    -DD'),TO_DATE(:b10,'YYYY-MM-DD'))
    1. Pour le second


    • En tete

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
                  Snap Id     Snap Time      Sessions Curs/Sess Comment
                --------- ------------------ -------- --------- -------------------
    Begin Snap:     18319 06-Oct-09 19:00:01       26       6.2
      End Snap:     18320 06-Oct-09 19:30:02       24       5.6
       Elapsed:               30.02 (mins)
    • Physical reads

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
     
                                                         CPU      Elapsd
     Physical Reads  Executions  Reads per Exec %Total Time (s)  Time (s) Hash Value
    --------------- ------------ -------------- ------ -------- --------- ----------
            152,371       19,563            7.8    8.3    65.01   1334.19  221651136
    Module: /logi/hraccess50/zf9/bin/RTSDGN@nyplsacc (TNS V1
    select NUDOSS  ,SOCDOS  ,NULIGN  ,TO_CHAR(DATABS,'YYYY-MM-DD')
    ,MOTABS  ,CDAXES  ,NUMDRO  ,TO_CHAR(DATDEB,'YYYY-MM-DD')  ,NUMTR
    A  ,TO_CHAR(DATFIN,'YYYY-MM-DD')  ,TEMDEB  ,TEMFIN  ,UNITE1  ,UN
    ITE2  ,NBRJOU  ,SALRF  ,SALRFD  ,SALRFX  ,TEMDEC  ,ZONEUT  ,TO_C
    HAR(DATEAG,'YYYY-MM-DD')  ,VALIDE   from ZYDA where (NUDOSS=:b1
    Ce que je ne comprend pas est pourquoi la requete ci-dessus (hash_value 221651136) n'apparait pas dans le rapport d'une heure Je m'attendais à la voir en seconde position

  4. #4
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    En jettant un coup d'oeuil à la requête exécutée lors du reports statspack (dans ORACLE_HOME/rdbms/admin/sprepins.sql et en recherchant ''SQL statements ordered by physical reads):

    select ...
    from stats$sql_summary e
    , stats$sql_summary b
    , stats$sqltext st
    where b.snap_id(+) = :bid
    and b.dbid(+) = e.dbid

    sachant que e est le snapshot de fin (end) et b celui de début (begin),
    on voit le rapport ne montre que les requêtes qui sont présentes dans le snapshot de fin (jointure externe).

    Et les requêtes présentes ce sont celles qui sont en shared pool (v$sql) à l'heure su snapshot.

    Donc, si ta requête est sortie de la shared pool entre 08:30 et 09:00, tu la verra dans un rapport qui se termine à 08:30 pas pas dans celui qui se termine à 09:00

    Merci, c'est une très bonne illustration du fait que les rapports statspack faits sur une durée trop longue ne servent à rien.
    30 minutes, c'est en général très bien.

    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

  5. #5
    Membre régulier
    Inscrit en
    Août 2009
    Messages
    107
    Détails du profil
    Informations personnelles :
    Âge : 49

    Informations forums :
    Inscription : Août 2009
    Messages : 107
    Points : 124
    Points
    124
    Par défaut tout s'explique
    ah ok ! j'ignorais ce mode de fonctionnement. Et il y a effectivement aucun intérêt à faire des rapports sur une longue durée.

    Encore merci !

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Mars 2007
    Messages
    750
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mars 2007
    Messages : 750
    Points : 341
    Points
    341
    Par défaut
    Est-ce qu'on peut dire la même chose pr les rapports AWR?

  7. #7
    Expert éminent
    Avatar de pachot
    Homme Profil pro
    Developer Advocate YugabyteDB
    Inscrit en
    Novembre 2007
    Messages
    1 821
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Developer Advocate YugabyteDB
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2007
    Messages : 1 821
    Points : 6 443
    Points
    6 443
    Billets dans le blog
    1
    Par défaut
    Oui, c'est même principe.
    Il faudrait vérifier la requête lancée pour le prouver.
    Cordialement,
    Franck.
    Franck Pachot - Developer Advocate Yugabyte 🚀 Base de Données distribuée, open source, compatible PostgreSQL
    🗣 twitter: @FranckPachot - 📝 blog: blog.pachot.net - 🎧 podcast en français : https://anchor.fm/franckpachot

Discussions similaires

  1. [2008R2] requetes les plus consommatrices.
    Par scazikiss dans le forum Administration
    Réponses: 5
    Dernier message: 05/06/2013, 14h03
  2. Liste des sessions les plus consommatrices
    Par orafrance dans le forum Contribuez
    Réponses: 0
    Dernier message: 30/12/2011, 15h34
  3. requête les plus consommatrices CPU
    Par smaildba dans le forum Administration
    Réponses: 4
    Dernier message: 29/09/2009, 11h22
  4. Requêtes les plus consommatrices
    Par orafrance dans le forum Administration
    Réponses: 7
    Dernier message: 25/09/2009, 10h22
  5. Requete récupérer les 3 numéros les plus grands
    Par nerick dans le forum Langage SQL
    Réponses: 2
    Dernier message: 05/01/2006, 14h51

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