Discussion :

[farenheiit]

Bonjour,

je dois analyser un rapport AWR assez rapidement et faire un rapport avec recommandations.
pouvez-vous y jeter un oeil (voir même 2 ) et me dire si certaines choses vous sautent aux yeux ? je vais faire pareil de mon côté.

j'ai mis le rapport HTML en pièce jointe.

merci de votre aide

[13thFloor]

Statspack analyzer (http://www.statspackanalyzer.com/analyze090630.asp) peut apporter une aide de premier niveau avec un report en format texte.

Après un rapide coup d'œil, je dirais :
- attente log file parallel write => écritures des redo pas assez rapides (redo et archives devraient idéalement être sur des disques isolés car les écritures se font séquentiellement). Mais relativisons : 1424", soit environ 25',sur 719', ce n'est pas bien lourd
- attente db file parallel write => peut être un manque de process db_writer (si tu as moins de 8 cpu ce ne sera pas nécessaire)
- essaies de réduire le nombre de buffer gets du sqlid 5qrsw9bnr332g => vérifier la sélectivité des index et leur clustering factor : un rebuild ou une recréation en reverse peut aider mais vu qu'il n'y a pas de buffer busy waits...
- essaies de réduire les accès physiques des sqlid fdmrd5j5wmh85 et 4gv43b9vr5qmv
- temps d'accès aux datafiles du tablespace M_TAB_COMMON pas top top (19 et 21 ms) => pas grand chose à faire car tout est sur /oradata1/ubix/
- augmentation de l'initrans des 4 index non-sys apparaissant en ITL waits (impact faible)
- optimizer_index_cost_adj et optimizer_index_caching settés => l'appli doit faire de l'index scan touzazimut

[farenheiit]

Statspack analyzer (http://www.statspackanalyzer.com/analyze090630.asp) peut apporter une aide de premier niveau avec un report en format texte.

Après un rapide coup d'œil, je dirais :
- attente log file parallel write => écritures des redo pas assez rapides (redo et archives devraient idéalement être sur des disques isolés car les écritures se font séquentiellement). Mais relativisons : 1424", soit environ 25',sur 719', ce n'est pas bien lourd
- attente db file parallel write => peut être un manque de process db_writer (si tu as moins de 8 cpu ce ne sera pas nécessaire)
- essaies de réduire le nombre de buffer gets du sqlid 5qrsw9bnr332g => vérifier la sélectivité des index et leur clustering factor : un rebuild ou une recréation en reverse peut aider mais vu qu'il n'y a pas de buffer busy waits...
- essaies de réduire les accès physiques des sqlid fdmrd5j5wmh85 et 4gv43b9vr5qmv
- temps d'accès aux datafiles du tablespace M_TAB_COMMON pas top top (19 et 21 ms) => pas grand chose à faire car tout est sur /oradata1/ubix/
- augmentation de l'initrans des 4 index non-sys apparaissant en ITL waits (impact faible)
- optimizer_index_cost_adj et optimizer_index_caching settés => l'appli doit faire de l'index scan touzazimut

Merci de t'intéresser à mon pb.
Comment interprète tu le Db Time par rapport au Elapsed time ?
Comment sais tu que 19 et 21ms c'est trop long comme temps d'accès au DBF ? c'est quoi le temps idéal ?Pourquoi dans ce cas ne pas avoir sité le tbs UNDO qui est à plus de 50ms ?

Pour 4 CPU je peux mettre combien dans db_writer_processes et dbwr_io_slaves ? actuellement les valeurs sont de 1 et 0.

j'ai pas compris la phrase suivante:

augmentation de l'initrans des 4 index non-sys apparaissant en ITL waits (impact faible)

Comment faire pour accélerer l'ecriture des redo ?

[13thFloor]

Comment interprète tu le Db Time par rapport au Elapsed time ?
Ta base a bossé 33% du temps : 719' écoulés dont 241' de cpu pour la base.
Comment sais tu que 19 et 21ms c'est trop long comme temps d'accès au DBF ?
=> long par rapport aux autres datafiles
c'est quoi le temps idéal ?
=> le plus bas possible (réponse facile)
Pourquoi dans ce cas ne pas avoir sité le tbs UNDO qui est à plus de 50ms ?
Car il est énormément sollicité en écriture (normal dans toute base oltp).
Donc temps de lecture souvent plus élevé.

Pour 4 CPU je peux mettre combien dans db_writer_processes et dbwr_io_slaves ? actuellement les valeurs sont de 1 et 0.
=> les valeurs sont bonnes. Par défaut oracle alloue 1 process dbwriter par lot de 8 cpu

j'ai pas compris la phrase suivante:
augmentation de l'initrans des 4 index non-sys apparaissant en ITL waits
ITL waits = attente dans l'entête du bloc afin d'y stocker les transactions concurrentes pour modifier le bloc (plus de place).
Initrans défini le nb mini de transactions concurrentes au sein d'un bloc.
Maxtrans le max. mais il se peut qu'il n'y ait plus assez de place dans le bloc pour stocker ces informations.
Autre possibilité : moins compacter les données dans le bloc en augmentant le pctfree (espace laissé libre pour la croissance d'une ligne) => objet à reconstruire, il occupera un peu plus de place
Mais vu le faible nb d'itl waits, ce n'est pas un souci.

Comment faire pour accélerer l'ecriture des redo ?
=> mettre les redologs sur disques dédiés non raid5
=> commiter par paquet plutôt que par ligne
=> changer de type de file-system s'il en existe un plus performant (exemple : jfs vs jfs2)
=> envisager le raw-device

L'essentiel du taf est quand même coté requête : limiter les buffer gets (consommateur de cpu) et limiter les physical reads.

[farenheiit]

ok merci beaucoup,

que pense tu de l'évènement d'attente numéro 5 (enq:KO - fast object checkpoint). Est-il significatif?

Si le CPU Time apparait en 1er dans la liste des évènements d'attente c'est bien qqchose de rassurant non ?

[khaled.gaied]

ya t'il un outil peut accepter un awr en format html puisque Statspack n'accepte que le format texte?

[Z3phur]

Bonjour,

pourquoi vous ne générez pas vos awr au format txt?

pour ce faire il y a tout ce qu'il vous faut dans @?/rdbms/admin/

il me semble que c'est celui la : awrrpt.sql

[khaled.gaied]

parce que c 'est un client qui génère le rapport en HTML et je ne peux pas lui demander de le générer encore une fois en txt

et normalement d'habitude je ne trouve pas des problèmes pour analyser les rapport de ce client sauf cette fois ci je trouve que le comportement de programme en question est très normal (il s'agit d'une interface entre 2 système en PRO C) et je ne trouve pas d'explication pourquoi elle passer beaucoup de temps (comme l habituel).

peut être y'a un autre programme qui lock une table utiliser dans l'interface.


DATETRAIT DATEFINTRAIT NBENREG

07/09/2010 02:35:07 07/09/2010 05:48:13 2679

21/09/2010 03:34:12 21/09/2010 07:23:52 530

[pachot]

Bonjour,

La première chose c'est la comparaison DB Time/Elapsed=241.52/719.49=0.33
Il y a en moyenne 0.3 session active.

La plupart des statistiques du rapport n'ont pas de sens sur une machine qui n'est pas très chargée.
Un rapport sur 12 heures n'a pas beaucoup de sens pour 2 raisons:
- les moyennes perdent leur sens
- les SQL récupérés sont ceux qui sont en shared pool lors du dernier snapshot. Pas forcément représentatif d'une activité sur 12 heures

Donc la première chose serait de prendre un rapport dur une période de pic de charge, une période où il y a un problème de performance.

que pense tu de l'évènement d'attente numéro 5 (enq:KO - fast object checkpoint). Est-il significatif?

C'est une opération en direct-path, qui bypasse le buffer cache (TRUNCATE, parallel query, ...) et qui doit donc s'assurer que ce qui est en cache est flushé sur disque. 'db file parallel write' mesure le même temps (c'est DBWR qui écrit pendant que la session attend sur 'enq:KO - fast object checkpoint'.

Ici il n'est pas significatif (10 minutes sur 241.52 d'activité). Mais ce serait intéressant de savoir d'où ça vient.

Y a-t-il un problème de performances, c'est à dire des utilisateurs trouvent que le temps de réponse est trop long ? à quel moment ? alors récupérer un rapport sur une période courte (5 - 15 min) de ce moment là.

Cordialement,
Franck.