Discussion :

[agdid04]

Bonjour à tous,

Je rencontre un problème de perf sur une base 9i, les traces oracle remonte des attentes I/O parfois > 50% du temps global de ceratines oracle, mais au niveau OS pas d'alarmes au niveau des I/O (pas de saturation), est ce qu'il y a d'autres pistes à exploiter ? ou ce problème en cache un autre?
Merci.
Crdlt.

[Mathias44]

Bonjour,

Si ton système ne sature pas, tes requêtes attendent tout de même l'acquittement de l'I/O. A partir de là, il y a plusieurs possibilités : tes requêtes peuvent être optimisées pour réduire les lectures de blocs, ton sous-système d'IO peut également être optimisé (changement des disques, gestion des systèmes de fichiers, meilleure répartition des datafiles...), ou les 2.

[fatsora]

Bonjour,

Active staspack et regarde les requetes le plus lourdes .

Il y a peut etre des requetes a optimiser ( c'est pas le bon index qui est utilisé ou il faut ajouter des index...)


Regarde aussi si les parametre SGA ,PGA sont bien alloués , pb sous allocation ou sur allocation , ce qui evite peut etre des acces disques

[13thFloor]

De quoi sont faites ces IO ? FTS ? accès par index ? temporaire ? lecture ou écriture ? switch de log ? checkpoints ? trop de parallélisme ?

FTS => optimiser la requête pour qu'elle utilise un index, ajouter un index, réduire le nombre de blocs par lignes (pctfree à 0), partitionner, baisser le high water mark (pas tout en même temps)

Index scan : vérifier la sélectivité de l'index utilisé, shrinker l'index ou le rebuilder

Consommation de temp => accroître la PGA (si tu n'es pas en sort_area_size, sinon augmenter ce paramètre)

Switchs de log excessifs => augmenter la taille des redo (ou travailler en mode nologging, ok pour une base de test, à éviter en production)

Checkpoints : sans doute trop de petits fichiers (mieux vaut 1 fichier de 10Go que 10 fichiers de 1 Go)

Dans le report statspack, il y a t-il des datafiles avec des temps d'accès supérieurs à 20 ms ? => redistribuer ces fichiers sur d'autres disques