Discussion :

[Ikebukuro]

Bonjour,

Mon client me dit que l'accès à certaines tables est lente, SANS plus d'information car c'est un ressenti des user, et il aimerait bien que je jette un oeil

Etant assez joueur et curieux de mon côté, je vais chercher des infos sur ces tables en partant un peu à l'aveuglette.


Mon objectif :
1) Trouver la fréquence des Select sur une table, avec les différents users
2) Trouver sur 24H00 le total du temps passé à exécuter les Select
3) Trouver les délais d'attente pour accéder à une table indépendamment du temps utilisé pour ramener en SGA les données et trier les données
4) Trouver la quantité de données en octets manipulées par chaque Select

Mes solutions :
1) J'ai mis en place un audit sur les Select via le package DBMS_FGA.
Dans la vue DBA_FGA_AUDIT_TRAIL je vais avoir les opérations tracées mais je trouve que les infos sont pauvres : je vais pouvoir grouper par jour et par heure les Select et avoir leur nombre mais je n'ai pas le temps d'exécution de chaque requête.

2) Dans la vue V$SQL j'ai des choses plus sympas :
ELAPSED_TIME : Elapsed time (in microseconds) used by this cursor for parsing, executing, and fetching - c'est un cumul je crois du nombre de fois que l'ordre SQL a été exécuté
CPU_TIME : CPU time (in microseconds) used by this cursor for parsing, executing, and fetching

EXECUTIONS : nombre de fois où le même Select a été exécuté?
LOADS : nombre de fois où l'objet a été chargé? On parle du chargement de l'objet en mémoire, de ses données? J’interprète comment cette valeur?

3) Les quatre valeurs suivantes ont l'air prometteuses mais comment les comprendre car, euh, le commentaire Oracle est quand même peu explicite.
Il s'agit de délai d'attente car des verrous ou des latches ont été posés sur des données auxquelles le Select veut accéder?
APPLICATION_WAIT_TIME : Application wait time (in microseconds)
CONCURRENCY_WAIT_TIME : Concurrency wait time (in microseconds)
CLUSTER_WAIT_TIME : Cluster wait time (in microseconds)
USER_IO_WAIT_TIME : User I/O Wait Time (in microseconds)

Un problème est que je ne sais pas quand V$SQL est vidée car le nombre d’enregistrements entre V$SQL et DBA_FGA_AUDIT_TRAIL n'a rien à voir donc dans V$SQL je n'ai qu'une fraction des Select qui m'intéressent.

4) Là, je ne vois pas où chercher...

Si vous avez d'autres idées sur ces histoires de lenteur, identifier les goulots d'étranglement dans Oracle je suis preneur.

[dell68]

Tu as les historiques dans le réferentiel AWR via les vues suivantes
DBA_HIST_SQLXXXXX, en éxécutant ceci tu les auras presque tous :

Code :

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

1
2
 
select table_name from dict where table_name like 'DBA_HIST%SQL%' ;

[mnitu]

L'idéal sera d'activer la trace SQL pour les traitements où l'utilisateur a l'impression que "c'est lent". Sinon utilisez StatsPack ou AWR si votre client possède la licence pour tracer si possible la session sinon la base. Il n'est pas nécessaire tracer 24 heures mais plutôt la période ou les utilisateurs travaillent et ils sont le ressenti de "lenteur".

[Ikebukuro]

Bon ben finalement on va utiliser AWR; c'est un peu lourd à lire mais c'est l'outil du client dont acte!