Discussion :

[genio]

Bonjour,
nous avons un logiciel sur Windows (Oracle 9i) qui nous pose des problèmes de perf...
J'ai suivi tout ça via OEM et j'ai effectué une copie d'écran d'un ordre qui est très pénalisant... je le joins à mon post...

Ce qui m'étonne c'est que j'ai 100% de lecture physique et logique ainsi que 100% de succès cache tampon.. mon analyse soft parse est à 75 % et cela me semble bon...
1°) Me trompe-je ?

Je sais que cet ordre n'utilise jamais d'index, et qu'il lit donc 86000 lignes, à chaque apel... mais à part ça, d'après vous, y-a-t-il un loup caché ?

J'ai aussi 2 autres question à poser :
2°) Etant en mode 'dedicated', pourquoi OEM me donne-t-il la taille UGA (qui n'est pas utilisée avec ce mode !)... est-elle exprmée en octet, KO ou en Méga ?
3°) entre la taille UGA et la taille de ma PGA, je ne retrouve pas mes petits car ma PGA_AGGREGATE_TARGET est à 30 Méga... quand à la UGA, je ne vois pas à quoi elle fait référence...

Pouvez-vous m'aider ?

[orafrance]

bah surtout l'événement d'attente principal c'est log_file_sync

A priori tu as un problème d'écriture de redo. Et j'ai du mal à comprendre comment tu peux avoir 100% de physical et de logical en même temps

[genio]

Ah tu vois hein, que c'est un cas spécial !
Trève de plèz, je n'arrive pas à comprendre (après un p'tit tour sur internet) ce que ce log_fil_sync apporte et pourquoi il est en attente...
Peux-tu m'expliquer en 2 mots ?

Merci encore pour ta réponse...

[orafrance]

c'est le temps passé à écrire dans les redos quand tu fais un commit notamment. Cela peut signifier 2 choses : tu commites trop souvent ou les perfs sur les redos sont nules (pb hardware, RAID 5, etc...)

[genio]

Merci beaucoup pour ta réponse...

A bientot !

[genio]

Ah si, juste unje petite..
Effectivement, l'application committe beaucoup trop... mais d'après près toi, le fait d'agrandir fortement les redo, peut-il réger mon problème ?

Merci encore pour ta réponse...