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...

[orafrance]

non, tu écriras toujours autant dans les redos. C'est pas un soucis de switch trop fréquent (je crois que dans ce cas c'est un autre event) mais bien un problème de contention sur LGWR (le process log writer).

Là t'as pas 36 solutions : soit tu réduis le nombre de COMMIT soit tu mets des disques plus rapide

T'as quoi comme solution de stockage et comment sont organisés les fichiers (dans les file systems) ?

Pour info : http://asktom.oracle.com/pls/asktom/...:1786570718514

[genio]

Ah malheureux, c'est pas de l'unix mais du Windows ! Et en plus, un serveur de recette... j'ai l'impression qu'il n'y a plus grand chose à faire non ?

[orafrance]

ça change rien, même sous Windows tu as des baies SAN avec plus ou moins de canaux, tu as du RAID, etc...