Discussion :

[Débéa]

Bonjour,

J'ai un serveur AIX 5.2 où tourne plusieurs bases 9.2.0.4. Parfois, des grosses requêtes BO écroulent le serveur (CPU à 100%) au détriment des petites transactions OLTP.

Volà ma question :

C'est curieux comme fonctionnement pour un OS multitâche. Il devrait répartir les ressources processeurs. Avez-vous le même fonctionnement ? Existe-t-il un paramètre ou AIX ou ORACLE ?

Sur un autre serveur HP, l'OLTP n'est jamais bloqué comme sur AIX !

Merci pour votre aide,

[Jaouad]

Normalement on distingue OLTP et batch notamment sur BO

N'est ce pas nuke_y ?

[bouyao]

Il y'a combien de CPU dans ton serveur ?

[Débéa]

c'est un bi-processeur 64 bit avec 6 GB de RAM. les disques sont sur une baie SAN.

Je sais ! on ne devrait pas faire du BO sur du OLTP !!! on est quelques fois dépassé par les evenements !

[bouyao]

Il y'a la paramètre caché

Code :

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

_cpu_count

Normalement dans ton cas il est à 2 pour tous les bases
Essaye de le mettre à 1 dans les bases OLTP et à 2 dans la base BO.
Sinon il faut optimiser tes requêtes.

[Débéa]

cpu_count est bien à 2 pour toutes les bases.

tu as des AIX ? As-tu le même type de fonctionnement ?

[orafrance]

j'imagine que les requêtes BO sont plus complexes et font du parsing consommateur. Quelle est la valeur du paramètre cursor_sharing

[bouyao]

Non, j'ai des ALPHA et du HP.
Dans la version 9i oracle calcule automatiquement le nombre de CPU dans la machine et il le fixe dans le paramètre caché _cpu_count.
J'avais le même problème quand il y'a du BO, alors j'ai optimisé les requêtes.

[Jaouad]

Non, j'ai des ALPHA et du HP.
Dans la version 9i oracle calcule automatiquement le nombre de CPU dans la machine et il le fixe dans le paramètre caché _cpu_count.
J'avais le même problème quand il y'a du BO, alors j'ai optimisé les requêtes.

est ce qu'il aller au dessus du paramétres CPU_COUNT ???

[Débéa]

j'imagine que les requêtes BO sont plus complexes et font du parsing consommateur. Quelle est la valeur du paramètre cursor_sharing

Code :

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

1
2
3
4
5
SQL> show parameters cursor_sharing
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
cursor_sharing                       string      EXACT

sur toutes les bases

[Jaouad]

il faudrait essayer avec similare

[bouyao]

est ce qu'il aller au dessus du paramétres CPU_COUNT ???

Non, Surtout pas.
Comme j'ai dit, il faut qu'il diminue à 1 dans les bases OLTP et il laisse à 2 dans la base BO.

Pour moi, je lancerai un STATSPACK pour voir les requêtes consomatrice et je les réglerais après.

[Débéa]

tu peux m'en dire plus sur ce paramètre ? (cursor_sharing)

[Débéa]

est ce qu'il aller au dessus du paramétres CPU_COUNT ???

Non, Surtout pas.
Comme j'ai dit, il faut qu'il diminue à 1 dans les bases OLTP et il laisse à 2 dans la base BO.

Pour moi, je lancerai un STATSPACK pour voir les requêtes consomatrice et je les réglerais après.

Pourquoi limiter à 1 les bases OLTP ?

Doc ORACLE :

Code :

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

1
2
Caution: 
On most platforms, Oracle automatically sets the value of CPU_COUNT to the number of CPUs available to your Oracle instance. Do not change the value of CPU_COUNT

[Débéa]

Je pourrais aussi utiliser les profiles pour limiter la CPU sur les requêtes BO !

Qu'en pensez-vous ?

[bouyao]

Doc ORACLE :

Code :

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

1
2
Caution: 
On most platforms, Oracle automatically sets the value of CPU_COUNT to the number of CPUs available to your Oracle instance. Do not change the value of CPU_COUNT

C'est quand il y'a une seule base.

Par contre, quand j'ai plusieurs bases sur la même machine je n'hesietrai pas à donner plus de CPU au bases critiques et moin de CPU au bases non critiques.

Pour moi, Una base OLTP est constitué de petites transactions qui demande moins de CPU.

Dans tous les cas ce ne resoud pas ton problème, le fait de modifier ce paramètretu gagnera pas beaucoup en performance.

Les solutions :
1. optimise tes requêtes
ou
2. installer la base BO dans un autre serveur.

[orafrance]

tu peux m'en dire plus sur ce paramètre ? (cursor_sharing)

il permet de définir le degré de ressemblance des curseurs pour réutiliser les plans d'exécutions... ça évite de parser trop souvent si les requêtes se ressemblent. Attention, ça a un impact non négligeable sur l'ensemble de la base

[Débéa]

Je pourrais aussi utiliser les profiles pour limiter la CPU sur les requêtes BO !

Qu'en pensez-vous ?

Vous ne m'avez pas dit ce que vous en pensiez ?

[Jaouad]

Voila ce que personnelement et de part ma petite expérience j'en penses.

Il te faut tout d'abord déterminer ce qui ralentit de maniére globale tes requêtes en Batch , cela peut se faire ne tracant les waits events ( ce qui doit être un reflexe ) ou alors d'effectuer un statspack pour voir le top 5.

Cependant et c'est la que je rejoindrait Bouyao, en régle génèrale les plus gros gain se font en optimisant les requêtes SQL.

Sous Ps , nous avons réussi a optimiser un batch de reporting ( contrôle analytique ) faisant passer son temps de traitements de 3 heures à 5 min uniquement par le tuning SQL ( ce batch est lancé 5 fois par jour )

Mais attention il n'existe pas de régles absolus

En tout cas Bon courage
Jaouad

[bouyao]

Je pourrais aussi utiliser les profiles pour limiter la CPU sur les requêtes BO !

Qu'en pensez-vous ?

Vous ne m'avez pas dit ce que vous en pensiez ?

Vraiment je ne sais pas comment limiter le CPU sur les requêtes BO.