Discussion :

[superfunky]

Bonjour,

Depuis quelques jours, les utilisateurs d’une de nos applications de production (utilisation d’une couche OLAP), enregistrent de très mauvais temps de réponse. Il n’y a pas de problème réseau, ni même de problème côté Citrix. Nous supposons donc que les soucis sont liés à Oracle.

Voici la configuration du serveur :
RHEL5.3
Dual quadri core
Mémoire totale : 32Go

Ci-dessous les stats du serveur (représentant une trentaine de connexion à l’application)
Mémoire : 91%
CPU : 13%
Charge : 1,06
Req lecture/s : 33,26
Req écriture/s : 323,17

Pour la partie Oracle :
Oracle Database EE 10g Release 2 Patch Set 2 : 10.2.0.3.0
Interim patches (3) : Patch 6195891, Patch 5556081, Patch 5557962

Pga_aggregate_target : 24Go
Sga_max_size : 3Go
Sga_target : 3Go
Java_pool_size : 160 Mo
Shared_pool_size : 160 Mo


Je ne suis pas du tout familiarisée avec Olap et plutôt débutante sur le Tuning Oracle.
J’ai trouvé une documentation Oracle : Oracle Performance Diagnostic Guide Slow Database, que j’ai commencé à suivre. J’ai donc généré les reports ASH et ADDM.
Une des premières actions a été de retaillé ma SGA à 3Go, selon les indications du rapport ADDM.
Toutefois, entre deux périodes, bonne performance et mauvaise performance, je n’ai pas de grande différence sur le Average Active Sessions, les valeurs sont à peu près identiques.

Parmi toutes les informations trouvées ressorties dans les rapports ASH et ADDM. J’utilise la documentation d’Oracle « Performance Tuning Guide », pour essayer d’interpréter les résultats fournis, mais je ne sais pas trop par où commencer !!!

Auriez-vous quelques pistes à me proposer, pour m’aider à trouver la source de mon problème ?

Merci d’avance pour vos réponses

[Laurent_du_78]

Il y a une procédure stockée qui prend plus de 6000 s CPU et 14Milions de Buffer Get

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
DECLARE job BINARY_INTEGER := :job;
 next_date TIMESTAMP WITH TIME ZONE := :mydate;
 broken BOOLEAN := FALSE;
 job_name VARCHAR2(30) := :job_name;
 job_subname VARCHAR2(30) := :job_subname;
 job_owner VARCHAR2(30) := :job_owner;
 job_start TIMESTAMP WITH TIME ZONE := :job_start;
 window_start TIMESTAMP WITH TIME ZONE := :window_start;
 window_end TIMESTAMP WITH TIME ZONE := :window_end;
 BEGIN begin dbms_aw.execute('define batch_mode variable text session');
 dbms_aw.execute('aw attach scenario_prgm ro');
 dbms_aw.execute('call attacher_aw(''RW'' ''SCENARIO'' )');
 dbms_aw.execute('call lanct_fileattente(''RHBUD'' ''SCENARIO'' )');
 end;
 :mydate := next_date;
 IF broken THEN :b := 1;
 ELSE :b := 0;
 END IF;
 END;

Elle est lancée par l'ordonnanceur (parlons Francais!!) Oracle

[superfunky]

Après recherches auprès des utilisateurs, il s'avère que cette procédure stockée n'est habituellement pas lancée en journée, mais uniquement la nuit, puisque ce sont des calculs.
Je remets donc deux autres rapports : FD_ashrp_1_0921_1200 correspond à une période de mauvaise performance. Et FD_ashrp_1_0921_1600 à une période correcte.
Je suis, actuellement, plus en train de chercher du côté des paramètres OLAP. Mais si quelque chose vous parle dans ces rapports, je suis avide de bonnes idées pour poursuivre mes investigations.
Merci d'avance pour vos réponses.