Discussion :

[farenheiit]

Bonjour,

qq'un connaiterait-il un site qui expliquerait comment interpéter un rapport statspack?

merci d'avance

[pifor]

Peut-être le site référencé par Burleson Consulting et ex Oraperf (non testés).

Il y également des notes intéressantes sur le blog de Jonathan Lewis.

Idéalement il faudrait comparer les rapports avec un état du sytème "normal" et un état du système "lent".

Vous pouvez aussi poster votre rapport ici avec les bonnes balises de formatage.

[farenheiit]

en fait j'essai d'optimiser un traitement batch qui dure un peu moins de 30h.
j'ai lancé un cliché statspack avant le traitement et un autre à un peu plus de la moitié (le traitement est tjr en cours).

J'ai édité le rapport statspack mais j'ai du mal à interpréter les résultats.

qq'un peut-il m'aider? comment puis-je mettre à disposition du forum mon rapport?

[orafrance]

Si le traitement est en cours, inutile de regarder le statspack. Toutes les infos sont dispo en live dans v$session_wait, v$system_event et autres tables du dictionnaire.

Statspack c'est plutôt pour trouver les maladies de la base, quand t'as un problème sur un traitement particulier une trace est plus utile

[farenheiit]

je sais mais j'ai pas encore préparé mes scripts pour requêter les vues dynamiques, j'aimerais juste interpréter dans un 1er temps mon rapport statspack pour voir pourquoi mon traitement batch est si long: est ce un pb de buffer cache?de tri?

[pifor]

Donnez-nous:

- la version d'Oracle
- la durée exacte du rapport Statspack
- le nombre de processeurs de la machine
- le rapport Statspack complet ou au moins les sections Cache Sizes, Load Profile, Instance Efficiency Percentages, Top 5 Timed Events, Events,
Instance Activity Stats, Tablespace IO Stats for DB, Buffer Pool Statistics for DB, Buffer Pool Advisory for DB, SGA Memory Summary for DB.

La bonne durée d'un rapport Statspack est 15 à 30 minutes.

[pifor]

pourquoi mon traitement batch est si long: est ce un pb de buffer cache?de tri?

Non car:

Buffer Hit %: 99.86 In-memory Sort %: 100.00

Vous avez 3316 * 60 * 1072 = 213 285 120 requêtes exécutées pendant la durée analysée: c'est énorme !

Vous avez environ 7 millions d'échanges entre l'instance et ses clients:

Code :

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

1
2
SQL*Net message FROM client     6,884,729          0    507,784     74  1,325.5
SQL*Net message TO client       6,884,728          0          8      0  1,325.5

Comme le temps d'attente de 507 784 secondes est supérieure à la durée d'analyse, cela veut dire que le batch semble tourner en paralllèle avec des sessions d'utilisateurs qui utilisent l'application. Est-ce le cas ?

Il faudrait mettre le traitement batch du début à la fin en mode trace avec les temps d'attente pour avoir les détails au niveau du batch en lui-même avec:

Code :

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

ALTER SESSION SET EVENTS '10046 TRACE NAME CONTEXT FOREVER, LEVEL 12'

Si le batch contribute pour une partie importante sur les 507 000 secondes d'attente, cela peut signifier que les programmes batch client travaillent plus que l'instance Oracle. Il est aussi possible ques les programmes batch exécutent trop de requêtes SQL qui à chaque fois retourne quelques lignes de données.


C'est sans doute un problème mineur mais vous avez aussi des temps d'E/S qui sont parfois trop longs (70/80 voir 100 ms) sur certains tablespaces.