Catégories: Statistiques, consistent gets, db block gets, parse calls, parse count, SQL*Net, Temps de réponse

Historiquement, les vues V$ collectent les durées en centisecondes (100ème de secondes).
Cependant, certaines vues utilisent une autre unité:

microsecondes (1000000ème de seconde):

TIME_WAITED_MICRO, WAIT_TIME dans V$SESSION_WAIT, V$SYSTEM_EVENT, V$SESSION_EVENT, V$ACTIVE_SESSION_HISTORY
CPU_TIME, ELAPSED_TIME dans V$SQL, V$SQLAREA
WAIT_TIME dans V$LATCH, V$LATCH_PARENT, V$LATCH_CHILDREN
ACTIVE_TIME dans V$SQL_WORKAREA, V$SQL_WORKAREA_ACTIVE

millisecondes (1000ème de seconde):

CPU_WAIT_TIME dans V$ENQUEUE_STAT

secondes:

CTIME dans V$LOCK

La liste est non exhaustive, et les commentaires sont bienvenus pour la mettre à jour

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.

J'ai traduit récemment un article de Doug Burns sur un concept très important lorsqu'on étudie les performances d'un système: améliorer le temps de réponse d'un traitement individuel, et améliorer le débit (throughput) d'un ensemble de traitement sont 2 objectifs différents, et souvent contradictoires.

Doug Burns donnait un exemple concret en différenciant la mesure du temps de réponse d'une session individuelle (response time) et la mesure du débit d'une charge globale (throughput). Jonathan Lewis montre ici de manière simple la théorie qu'il y a derrière. Pour aller plus loin dans la théorie, je traduirais prochainement les commentaires de Cary Millsap là dessus.

Je n'ai pas l'intention de rentrer dans la technique des files d'attentes (Queuing Theory) qui est plutôt le domaine de Cary Millsap, mais je voudrais juste donner un exemple pour montrer de quelle manière la théorie des files d'attentes (Queues) s'applique à Oracle, en répondant à la question suivante que m'a posé un client récemment:

"Comment peuvent-ils se plaindre que le temps de réponse a empiré, alors que le débit (throughput) global a augmenté de 5% ?"

La réponse malheureusement est: oui, bien sûr, le temps de réponse est peut-être pire et ceci vient justement du fait que le débit est meilleur, et je vais donner un exemple dans cette note, construit pour montrer comment cela peut se produire.

» Lire la suite!

Cet article est la traduction d'un article de Doug Burns publié sur son blog. L'article original en anglais se trouve ici.
C'est une réflexion sur la principale métrique de performance: le temps de réponse, ou le débit (nombre de transaction par unité de temps) en fonction de ce qui est étudié: requête d'une session individuelle, ou charge globale d'un système (workload).

J'ai été incité à écrire cet article a la suite du commentaire suivant que Niall Litchfield a fait dans un email:
"... Je remarque qu'une fois qu'on commence à définir une charge globale de travail (workload), ou un ensemble de transactions, dans des termes métier (du genre 'j'ai besoin d'effectuer toutes ces choses, qu'est-ce qui marche le mieux ?') alors le temps de réponse de la charge de travail complète ^* a un sens, d'une part comme métrique, mais surtout comme un objectif de tuning. J'ai l'impression que depuis ces 10 dernières années, les discussions sur les performances se font autour des requêtes, ou de l'optimisation d'une session, en supposant que si on améliore les performances d'une requête particulière, alors on va aussi améliorer la charge de travail complète, telle que le voit le métier. C'est souvent vrai, mais c'est souvent faux aussi. Les mesures de performances seront toujours basées sur le temps de réponse, mais il pourrait y avoir des d'autres méthodes de tuning. Ça pourrait être aussi simple que de définir la première étape du tuning comme 'Définir la charge de travail (workload) la plus importante important pour le métier' au lieu de 'définir la tâche importante pour le métier'

Je suis d'accord avec Niall, particulièrement sur le fait actuellement on met plus l'accent sur l'optimisation de sessions individuelles, ou des requêtes isolées, plutôt que l'optimisation de la charge de travail globale.

Je vais dire cela d'une autre manière: si vous essayez d'avoir le meilleur débit pour toute la charge de travail (workload throughput) alors l'objectif le plus important n'est peut être pas le meilleur temps de réponse d'une session individuelle.C'est pourquoi j'ai quelques slides d'un cours que j'ai écris auparavant pour Oracle et qui définissent plusieurs façons d'évaluer les performances du système, incluant:

• le temps de réponse (response time)
• le débit (throughput)
• et l'évolutivité (scalability)

» Lire la suite!

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.
Il montre un fonctionnalité peu connue: la compression des données transférées par SQL*Net lorsque il y a répétition de valeurs d'une ligne à l'autre. Et l'avantage de récupérer ces données triées sur ces colonnes répétitives.

Voici une petite démonstration que j'avais l'intention d'écrire depuis ces dernières années.
C'est très simple: je crée une table, et je l'interroge plusieurs fois.

» Lire la suite!

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.

Il y a beaucoup de confusion sur la statistique 'parse calls'.
Ce qu'il est important de retenir, c'est qu'elle compte seulement une certain type d'appel à la librairie OCI (Oracle Call Interface - l'API d'accès aux internes natives d'Oracle).
La charge de travail effectuée par un 'parse call' est très variable en fonction des circonstances, et parfois tellement minime qu'il n'y a pas lieu de s'en inquiéter.

Un 'parse call' peut:

• (a) Devoir optimiser la requête car il ne l'a pas trouvée après l'avoir cherchée en library cache.
• (b) Trouver la requête en library cache, mais avoir quand même à l'optimiser pour diverses raisons. Par exemple: le plan d'exécution précédant a été vidé du cache. Ou bien le même texte de la requête s'applique à des objets différents, on fonction de celui qui l'exécute.
• (c) Trouver la requête en library cache, et ne pas avoir à la ré-optimiser parce que le plan est toujours disponible, et que le user a les droits appropriés.
• (d) Passer par le cache des curseurs de la session (session cursor cache) ou celui du moteur pl/sql (pl/sql cursor cache) qui permet d'utiliser un raccourci vers la requête en library cache, sans avoir à faire de recherche.

Lorsque le compteur 'parse calls' est incrémenté, vous devez toujours vous demander si cet appel s'est traduit par la situation (a), (b), (c) ou (d).

Et juste pour embrouiller les choses, oracle peut compter un 'parse count (hard)' sans compter un 'parse call' (voir ici).

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.
Jonathan Lewis donne la définition des statistiques qui concernent les parsing des requêtes : session cursor cache hits parse count (total) parse count (hard) execute count Vous trouverez aussi quelques mots sur le parsing ici

Voici un extrait d'un rapport que j'ai fait récemment sur l'activité d'une session. Cherchez l'erreur:

Name                           Value
----                           -----
session cursor cache hits          3
parse count (total)                5
parse count (hard)                31
execute count                     35

Il n'y a pas d'astuce particulière pour avoir ce résultat, même si l'activité de la base de données est un peu particulière, et je n'ai pas trafiqué les chiffres. Alors comment se fait-il qu'on ait plus de 'hard parse' que de 'parses' ?

Je n'aime pas du tout le terme 'hard parse', je ne suis pas très enthousiaste à propos de 'soft parse', et je suis irrité par la confusion fréquente où l'on ne distingue pas les 'parse calls' et le parsing.

Les statistiques que j'ai cité, et qui semblent bizarres, s'expliquent facilement.
'parse count (hard)' devrait plutôt s'appeler 'optimizations', et ces optimisations d'une requête peuvent être nécessaires pour l'appel de l'exécution de la requête ('execute call') aussi bien que pour l'appel de parse de la requête ('parse call').

Les 'parse count (total)' devraient plutôt être appelés 'parse calls', et il y a des 'parse calls' qui ne nécessitent aucun parsing, lorsque la requête se trouve dans le cache des curseurs de la session (session cursor cache).

Tout ce que j'ai fait pour cette démonstration se trouve dans ce simple bloc pl/sql:

declare 
  m_n  number; 
begin 
  for i in 1..30 loop 
    select count(*) into m_n from t1; 
    dbms_lock.sleep(1); 
  end loop; 
end; 
/

Mais il faut noter l'appel à dbms_lock.sleep. Lorsque ce bloc a été exécuté, j'ai fait un truncate de la table t1 toutes les secondes à partir d'une autre session.

Parce que je suis en pl/sql, le select est automatiquement retenu dans le cache des curseurs, il n'est parsé qu'une fois et exécuté 30 fois, donc il n'y a pas 30 'parse calls', mais un seul 'parse call' et 30 'execute calls'

Mais parce qu'il y a les truncate à chaque fois dans l'autre session, le plan d'exécution qui été généré pour la requête au moment du 'parse call' (qui a parsé, optimisé et gardé le curseur ouvert) s'est trouvé invalidé à peu près à chaque exécution.

Alors, pratiquement à chaque exécution, il a fallu réoptimiser la requếte à nouveau. Si vous vérifiez V$SQL vous verrez que le curseur fils a subi 30 invalidations et loads.

En résumé:

'parse count (total)' est le nombre de demande de parse ('parse calls'). Si la requête n'a jamais été vue avant, cela entraîne un parse et une optimisation. S'il elle a déjà été vue, celà entraine une recherche dans le 'library cache' (c'est la manière de savoir qu'elle a déjà été vue) et peut entraîner un 'cursor authentication'. Si elle a déjà été vue, et authentifiée, et qu'elle a une entrée dans le cache de session (session cursor cache) alors l'appel de parsing 'parse call' ne fait quasiment rien, parce qu'il n'y a même pas besoin de faire de recherche dans le library cache vu qu'il a été implicitement retenu.

'parse count (hard)' est le nombre d'optimisation qui ont eu lieu. L'optimisation peut être la conséquence d'un 'parse call' ou bien d'un 'execute call'. Même un curseur qui a été retenu peut avoir eu son plan d'exécution invalidé, ce qui entraîne une réoptimisation à la prochaine exécution.

'session cursor cache hits' est le nombre de fois où un 'parse call' n'a eu quasiment rien à faire parce que la requête a été retenue automatiquement lorsque la couche OCI a dérecté une utilisation répétée de la requête.

Ajout:

Il y a une autre statistique dont je n'ai pas parlé. Elle n'apparaît pas souvent dans un rapport statspack, mais pour être complet, je dois le mentionner car cela peut embrouiller les choses.

Si vous exécutez une requête qui a une erreur au parsing (comme select ssdate from dual) alors l'optimiseur retourne l'erreur qui correspond (ORA-00904 dans cet exemple). La statistique 'parse count (failures)' est incrémentée, tout comme 'parse count (hard)'.

Mais malheureusement, 'parse count (total)' peut ne pas changer. C'était le cas lorsque j'ai essayé à partir de SQL*Plus en version 9.2.0.8, mais elle a été incrémentée lorsque j'ai essayé en 10.2.0.3. C'est donc une autre cas où l'on peut avoir plus de 'hard parses' que de 'parses'.

Si vous voyez beaucoup de 'parse count (failures)', vous allez aussi voir les évènements de waits correspondants: 'SQL*Net break/reset to client' (ou dblink, selon d'ou vient la requête).

Cet article est la traduction d'un article de Jonathan Lewis publié sur son blog. L'article original en anglais se trouve ici.

L'article explique à quoi correspondent exactement 'db block gets' et 'consistent gets' que l'on retrouve dans les statistiques de performance à différents endroits: autotrace, statspack, AWR, V$SESSTAT

Dans tkprof, on retrouve 'db block gets' dans la colonne 'current' (version courante du bloc) et 'consistent gets' dans la colonne 'query' (version consistante par rapport au début de la requête)

Dans V$SQL on retrouve leur somme, sans les différencier, dans la colonne BUFFER_GETS. Leur somme est aussi souvent appelée 'logical I/O' (LIO) ou 'Lectures en mémoire tampon' sous OEM et s'incrémente à chaque fois qu'oracle va lire un bloc en buffer cache en passant par le 'cache buffer chain', donc en nécessitant un latch - verrou sur cette structure mémoire.

'db block gets' et 'consistent gets' sont deux contextes différents de ces lectures logiques: version courante ou version consistante du bloc.

Comment décrire 'db block gets' and 'consistent gets' en quelques lignes ? Ayant posé la question sur mon blog je suppose que je dois donc donner ma version de la réponse.

» Lire la suite!