Discussion :

[devkais]

Bonjour

Voici les Top 5 de mon AWR :

Event Waits Time(s) Avg wait (ms) % DB time Wait Class
DB CPU 28,205 69.90
db file sequential read 19,542231 5,522 0 15.93 User I/O
db file scattered read 113,503 1,025 8 3.73 User I/O
direct path write 41,371 463 15 1.24 User I/O
direct path write temp 9,52 118 14 0.31 User I/O

db file sequential read (lecture indexée) est élevé = 172 fois db file scattered read (full scan).
Est-ce normal pour un traitement batch ?
Quelle est la différence entre les évènements direct path write et direct path write temp ?
Quelles sont les évènements les plus classiques dans le TOP 5.
Comment faut-il lire DB CPU ? quand est ce cas sa valeur est alarmante ?
Quelle est la colonne la plus pertinente à lire dans le top 5 ?
merci pour votre aide

[pachot]

Bonjour,

db file sequential read (lecture indexée) est élevé = 172 fois db file scattered read (full scan).
Est-ce normal pour un traitement batch ?

C'est vrai qu'on s'attend plutôt à des scattered read pour du batch.

Quelle est la différence entre les évènements direct path write et direct path write temp ?

Le deuxième écrit dans les tempfiles (sort, hash join, GTT,...).
Le premier écrit dans datafiles (insert parallel ou append)

Comment faut-il lire DB CPU ? quand est ce cas sa valeur est alarmante ?

Il faut le comparer au temps elapsed. Si le rapport couvre 12 heures, alors 28,205 secondes de CPU c'est moins d'une CPU occupée.

Quelle est la colonne la plus pertinente à lire dans le top 5 ?

% DB time bien sûr. Par exemple inutile de se préoccuper de 'direct path write temp' qui ne prend que 0.31% de l'activité totale

Sinon, beaucoup de CPU, beaucoup de lectures multibloc, il fait aller voir les SQL order by Gets.
Ca sent du traitement ligne à ligne. Peut-être un plan d'exécution a tort en nested loops.

Cordialement,
Franck.

[devkais]

Bonjour Franck ,

Selon un support de formation Oracle il avait cette remarque :

Le référentiel AWR (Automatic Workload Repository) et les états Statspack
indiquent le temps CPU et le temps d'attente dans la section "Top 5 Timed Events" si le temps CPU fait partie des cinq principaux événements.

Temps BdD = Temps CPU BdD + Temps d'attente BdD

Lorsque des contentions sont mises en évidence par une hausse du temps d'attente, l'ajout de
nouvelles CPU à un noeud ou de nouveaux noeuds à un cluster apporte une amélioration très limitée.

J'ai 2 questions :

1/ et si le temps CPU ne fait pas partie des Top 5 ? comment interpréter ?
2/ Si le temps d'attente est prépondérant => contentions => application non évolutive => L'ajout de CPU ne résout pas les problèmes de perfs dans ce cas.

Dans ce cas comment détecter et résoudre les contentions ?

Merci pour précisions d'Expert.

[mnitu]

J'ai 2 questions :

1/ et si le temps CPU ne fait pas partie des Top 5 ? comment interpréter ?
2/ Si le temps d'attente est prépondérant => contentions => application non évolutive => L'ajout de CPU ne résout pas les problèmes de perfs dans ce cas.

1/ La base est ouverte mais personne ne travaille.
2/ Si vous attendez sur le quai d’une gare parce que le personnel de la SNCF est grève en quoi le fait d’attendre le TGV ou le train régional fera une différence

Dans ce cas comment détecter et résoudre les contentions ?

.

Lorsque des contentions sont mises en évidence par une hausse du temps d'attente

[pachot]

Bonjour,

1/ et si le temps CPU ne fait pas partie des Top 5 ? comment interpréter ?

Ce serait très étonnant. Toute activité nécessite de la CPU. Ca voudrait dire que tout est bloqué je pense.

2/ Si le temps d'attente est prépondérant => contentions => application non évolutive => L'ajout de CPU ne résout pas les problèmes de perfs dans ce cas.

Ça dépend. Des attentes disque, ça peut être scalable en ajoutant des disques. Et trop d'utilisation CPU, c'est peut être louche aussi.
Oracle a plutôt intérêt à faire rajouter des CPU vu qu'on paie des licences dessus

Cordialement,
Franck.

[devkais]

Bonjour
Avant de clôturer ce post je souhaite rajouter une question :
Admettons que mon traitement à diagnostiquer a tourné de 9h30 à 11h15.
Dans ce cas sur quelles périodes dois je exécuter mon AWR ?
Sachant que j'ai des snapshots (par défaut) toutes les heures 9h 10h 11h 12h.
Certes je dois analyser celui de 10h-11h mais y a t il mieux pour ne rien rater dans le traitement ?
Si j'ai la possibilité de relancer le traitement à analyser ,dans ce cas il vaut mieux lancer un create_snapshot juste avant de lancer et juste après la fin du traitement pour avoir un AWR précis ?
Thanks.

[pachot]

Bonjour,

Voici mon approche:
create_snapshot au début et à la fin, et tous les 15 minutes pendant le traitement.
Ensuite j'analyse un rapport qui couvre toute la durée. Si je vois qu'il est complet, par exemple j'analyse les sections SQL et j'ai:

Code :

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

-> Captured SQL account for   95.4% of Total DB Time (s)

Alors ça me suffit.

On trouve ce pourcentage dans plusieurs sections.
Si je vois que le rapport complet n'a qu'un faible pourcentage, alors je vais regarder des rapports plus courts.

Cordialement,
Franck.

[tropiko]

Bonjour
Existe t il un moyen de forcer la capture de toutes les requêtes dans une période ?
@devkais 1h est la durée recommandée par Oracle pour un AWR.
Si traitement court alors ASH.

[pachot]

Bonjour
Existe t il un moyen de forcer la capture de toutes les requêtes dans une période ?
@devkais 1h est la durée recommandée par Oracle pour un AWR.
Si traitement court alors ASH.

Le problème n'est pas là. AWR les capture à partir de la shared pool (v$sqlstat) est elles n'y restent pas indéfiniment.
Donc si beaucoup de requêtes différentes celles du début du traitement n'y sont plus au moment de la capture du snapshot final.

[ora_home]

Bonsoir Pachot,
que ce que vous en pensez du AWR ci-joint ? quelles sont vous remarque dès le première regarde ??

[pachot]

Bonjour,
Au premier regard, le temps CPU est relativement très faible par rapport au reste. Cela s'explique par le fait qu'on fait proportionnellement beaucoup d'i/o (environ 1 bloc sur 2 n'est pas en cache).
La requête 9mg94s1kfs74x a probablement quelque chose à optimiser. Mais attention, le rapport n'a capturé qu'une petite partie des SQL
Cordialement,
Franck.

[ora_home]

Salut Pachot,
Oui éffectivement, j'ai déjà optimisé la requete "9mg94s1kfs74x", et elle a donné un plan d'exécution optimale, mais juste pour la requete, et non pas pour l'application.

Alors notre cas, est que :
1) on a pas la main sur le code applicatif (donc on a pas le droit de ré-écrire certains requêtes)
2) Il y a une table principale "TOSTOCK" qui fait plus de 6000 000 Enregistrements, et qui est solicitée par tous les traitement de l'application, alors enfin de compte je me suis rendu-compte que cette table n'a pas de CLE PRIMAIRE (ce qui bizaaard), l’éditeur a crée 7 indexs (index combinés) sur cette table.

Alors que ce que vous proposé comme actions ???

[pachot]

Ah, donc il existe un plan d'exécution. Il faut essayer de l'avoir avec l'appli (statistiques, profiles, etc)

[devkais]

Sinon, beaucoup de CPU, beaucoup de lectures multibloc, il fait aller voir les SQL order by Gets.
Ca sent du traitement ligne à ligne. Peut-être un plan d'exécution a tort en nested loops.

Cordialement,
Franck.

Bonjour Franck ,
peux tu stp me donner plus d’explications sur "sql order by gets" et quand faut il vérifier ce point ? Points alarmants ?
merci

[pachot]

Bonjour,
"sql order by gets" c'est les requêtes qui lisent le plus de blocs (logical reads - pas forcément des i/o s'ils sont en buffer cache), c'est intéressant de comparer le nombre de blocs lus avec le nombre de lignes du resultat. Par exemple lire 600000 blocs pour ramener 0 lignes (exemple vu cette semaine) montre probablement un plan d'exécution inefficace qui ne commencent pas par l'index le plus selectif.
Cordialement,
Franck.