Discussion :

[abdou_ci]

Bonjour
J'ai un probleme de lenteur au niveau d'une application qui roule sur oracle 10g et ayant trois serveurs d'application oracle sur deux sites diffrents.
en effet j'ai la database et deux serveur application pracle sur un même site, et le 3eme serveur appli sur un site distant; les deux sites sont reliés par une connxion radio de 10MB.
mon problème est que mes utilisateurs n'arrivent pas à travailler correctement tellement c'est lent.
Mais rassurer vous le test réseau donne de bon resultat.
Alors j'aimerais savoir s'il ya des paramètres pour ameliorer les performances au niveau serveur appli et base de donnée afin que la connexion a la base et au serveur appli puisse être rapide.
(J'ai environ 250 utilisateurs)
merci

[lmartin]

Il y a pas mal de paramètres du serveur Oracle qui peuvent influer sur tes performances.
Il y en a un autre qui est ton code ....

Tu peux commencer en regardant PGA_AGGREGATE_TARGET et SGA_TARGET

[13thFloor]

Tu soulèves 2 problèmes : lenteur dans l'application et lenteur pour l'établissement des connexions.
Tu as les 2 soucis ?

Coté appli et base de données, si c'est long c'est que (entre autre) :
- tes utilisateurs manipulent de gros volumes de données ou font des calculs dessus et oracle déterminent mal la façon de traiter les informations demandées
=> manquent de statistiques (en principe non car 10g mais à vérifier)
=> io mal réparties
=> indexation insuffisante

- des commit se font attendre (verrouillage/enqueues)
- trop de monde accède aux mêmes informations au même moment
=> mettre en cache les tables les plus fréquemment accédées
=> limiter les full table scan (en partitionnant ou indexant par exemple)
=> réduire le nombre de lignes par blocs

Commence par nous dire ce que donne en report de statspack pendant une période de forte activité : quelles sont les attentes ? les objets les plus sollicités en buffer gets, disk reads et buffer busy waits ? les temps de réponses des datafiles ? pga satisfaisante ?
Quelle est la charge coté système : iowait ? il y a du "gras" ?

[abdou_ci]

Coté appli et base de données, si c'est long c'est que (entre autre) :
- tes utilisateurs manipulent de gros volumes de données ou font des calculs dessus et oracle déterminent mal la façon de traiter les informations demandées

Je pense que depuis le debut le problème est que les users manipulent de gros volume de données en même temps.
En fait j'utilise une application des impots donc à la periode de pic tous les utilisateurs essayent de se connecter en même temps pour efffectuer des operations diverses, donc comme les sites sont eparpillés et reliés par la radio, il arrive 1 moment où il ya engorgement. donc l'edition d'un reçu qui prenait avec l'ancienne base 9i doublée d'une archi deux tier, prend plus de 10mn avec la version web.
merci

[13thFloor]

...donc l'edition d'un reçu qui prenait avec l'ancienne base 9i doublée d'une archi deux tier qui durait on ne sait pas combien de temps, prend plus de 10mn avec la version web.
merci

Si c'est bien le cas (à confirmer), voici quelques pistes :
accès en lecture :
-activer le buffer KEEP et placer les tables les plus souvent accédées dans ce buffer
- indexer différemment pour éviter les full table scan
- éventuellement partitionner certaines tables très volumineuses si un critère de partitionnement est représentatif des clauses where sur ces tables
- si les fts ne peuvent être éliminés, compacter la table pour diminuer le high water mark et parcourir moins de blocs (alter table ma_table shrink space ou ancienne méthode : alter table move+rebuild index)
- calculer des histogrammes sur les colonnes utilisées dans les clauses where (hors colonne de primary key)
- répartir les IO en redistribuant les datafiles

accès en mise à jour :
- si trop d'accès simultanés aux mêmes blocs => réduire le nombre de lignes par blocs => augmenter le pctfree et move de la table (+ rebuild de ses index)
- vérifier si les tablespaces sont bien en assm
- vérifier le nombre de switch de logs (fonction de la politique de backup et de la perte de transaction toléré) => trop de switch nuit mais est bénéfique en cas de reprise d'activité suite à un sinistre ou un crash

Mais il faut au préalable vérifier quels types d'attentes se produisent.

[orafrance]

Tu peux commencer en regardant PGA_AGGREGATE_TARGET et SGA_TARGET

j'aimerais bien savoir en quoi ça pourrait l'aider

Ca part dans tous les sens dans ce topic

Le premier point à éclaircir il me semble c'est de savoir si le problème vient de la base ou du réseau (au moins la quantité de data ramenée). Est-ce que si tu attaques les serveurs d'appli en local les perfs sont correctes ? Si oui, alors oublie les paramètres base de données, si non alors identifie les requêtes qui posent problèmes avant de t'attaquer à la base au complet.

[abdou_ci]

Je ne pense pas que le problème soit réseau, mais surtout au niveau database.
Car pour eviter l'engorgement, nous avons augmenter les serveurs appli oracle à 4 au lieu de 2; et les gens commencent à travailler, mais à un certain moment les utilisateurs appellent pour dire que c'est géléé ça veut que les rçus ne sortent plus et cela dans tous les sites delocalisés, donc j'imagine qu'il ya un problème de communication soit entre la base et les serveurs appli, ou que la base est saturée par les demandes à un moment donnée; car pour eviter il nous faut redemarer le serveur a chaque fois.

[orafrance]

si l'upgrade du serveur appli améliore le problème c'est plus l'appli qui délire que la base non ?