Discussion :

[Milo59000]

Bonjour à tous,

Je voudrais une précision sur les sessions Oracle.

Je travaille sur une base 9.2.0.8 avec Siebel 7.2.0.8 et on recontre des problèmes de performances.

Je m'explique :
On a pic à un moment de la journée, c'est-à-dire un ralentissement de l'application. Les utilisateurs se plaignent bien entendu de ces désagréments.

Lors du pic, on a environ 2700 sessions Oracle (sessions utilisateurs et autres processus oracle). Ces problèmes sont assez récents. Avant ces problèmes, on avait environ 1700 sessions Oracle.

On constate également un problème d'allongement de requête lors de ce pic.

La précision que j'aimerai avoir est donc :
- Lorsqu'une session Oracle est créée, Oracle attribue de la mémoire à cette session (dans la PGA qui stocke les curseurs, bind variable...)
- L'allongement du temps des requêtes est-il en rapport avec le manque de mémoire disponible ?
- Comment voir l'espace PGA/SGA encore disponible ?

En gros, comment faire pour trouver l'origine de ces lenteurs ?

Merci.

[star]

Je ne vois qu'une solution pour circonscrire l'origine du problème : une métrologie en bon éduforme.
Blague à part, c'est vrai que tracer une base Oracle n'est pas très évident lorsqu'on n'est pas DBA. C'est comme diagnostiquer une panne sur une fusée Ariane en cours de vol pour Jupitaire.
Donc, je dirai à vue de nez par un petit calcul mathématique 2700 - 1700 = 1000 sessions multiplier par une moyen d'occupation mémoire de aller 1M, ce qui nous fait 1Go de ressources consommées. A vérifier par rapport à la taille mémoire physique avant constatation du rallentissement des transactions.
En espérant que cela puisse aider.
.

[pachot]

Bonjour,
La question principale est: est-ce que ces sessions sont en dedicated server ou en shared server ?
En dedicated, chaque session va avoir son process avec sa mémoire.
Les consequences sont:
- plus de mémoire utilisée sur le système. Là il faut juste vérifier que les système ne se met pas à swapper, sinon les performances vont s'écrouler.
- en workarea_size_policy=automatic, pour qu'oracle essaie de ne pas dépasser pga_aggregate_target, il va allouer moins de mémoire à chaque session. Donc des tris peuvent alors devoir se faire sur disque alors qu'ils se faisaient en mémoire avant. Et des plans d'exécution peuvent changer: des hash joins qui se faisant en mémoire peuvent alors être trop couteux.

Donc à voir en premier:
-> au niveau de l'OS la mémoire disponible, et si le système swappe
-> au niveau oracle, un rapport statspack ou AWR sur 1/4 heure pendant le pic, à comparer avec un idem en dehors du pic

Et les solutions:
-> paramétrage différent de PGA
-> passage en shared server éventuel

Cordialement,
Franck.

[Ahmed AANGOUR]

Autre solution un peu bourrin: Ajouter du Hardware
Mais ça ne fait que repousser le pb dans le temps.
Si de nouveaux le nombre de sessions simultanées augmente le pb se reproduira.
Donc il faudrait dans ton cas passer en Shared Server.
Si t'es déjà en Shared Server il faudrait checker la valeur des paramètres DISPATCHERS et MAX_DISPATCHERS. Et dans ce cas ce ne serait pas la PGA à tuner mais la SGA car l'UGA se situe dans la LARGE POOL.

cdmt,
Ahmed

[Pomalaix]

...Donc il faudrait dans ton cas passer en Shared Server.

Bonjour

Pour moi, présenter les serveurs partagés comme étant la solution, sans en savoir plus sur l'application, est une erreur.
Avec les serveurs partagés, le remède peut être pire que le mal si les circonstances ne s'y prêtent pas.

[Ahmed AANGOUR]

On fait juste avec le peu d'info qu'on a.
Il faut sous entendre par solution, une solution à ENVISAGER.
Les soucis de perf décris par Milo59000 correspondent aux symptômes des limites du mode dedicated server . Ca ne veut pas dire pour autant que le shared server est la solution. Mais c'est forcément qqchose à envisager.

Mais t'as bien raison de rappeler qu'il ne faut pas tout prendre pour argent comptant.

cdmt,
Ahmed