Discussion :

[puck78]

Bonjour,

J'ai une incohérence dans une base entre ces deux résultats:
- show parameter session: sessions vaut 635
- init.ora: sessions vaut 335

Pourquoi les deux chiffres sont-ils différents?

Je précise à tout hasard que la base est repliquée (même si je ne vois pas le lien à priori)

Merci!

[Heaven93]

bonjour,


peut-être devriez-vous vérifier que c'est sur l'init que la base a démarré. il est très probable qu'elle ait démarré sur le spfile où vous devriez lire la valeur attendue.

[puck78]

Effectivement, le fichier init.ora ne semble pas être utilisé car j'ai changé le nombre de sessions, arrêté et redémarré la base et aucun changement n'a été constaté....

Le fichier spfile est un binaire, mais dans les caractères lisibles on y retrouve bien sessions=335?

[Heaven93]

un

Code :

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

show parameter spfile

montrera le fichier d'initialisation utilisé par la base. si cette requête ne ramène rien, alors essayer la même commande avec pfile à la place de spfile.
il n'y a aucun problème pour visualiser un spfile avec vi sous unix (vous êtes sous windows?)
en tout cas, vous devriez trouver le paramètre valorisé à 635 dans le fichier d'initialisation utilisé par la base.
voulez-vous changer la valeur du paramètre?

[puck78]

Merci pour la commande sql, je vais tester ca dès demain.
Je n'ai pas trouvé de fichier pfile sur le serveur, mais des fichiers spfile_<ma base>.ora

Sinon, oui je suis sous Linux. J'ai fait un

Code :

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

strings spfile_<ma base>.ora

pour en voir les caractères.
Perso, je n'ai jamais été très à l'aise avec vi! Par curiosité, j'essayerais demain pour voir si ca donne le même résultat que strings ou pas?

Pour changer ce paramètre dynamiquement un

Code :

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

alter system set session=xx

suffit, je crois?
(Il ne s'agit pas de changer ce paramètre définitivement, juste de le diminuer temporairement pour faire des tests).

[Heaven93]

de mémoire, je dirais qu'il n'est pas dynamique, et qu'il faudra un scope=spfile à la fin de la commande et redémarrer la base (je crois aussi que c'est sessions au pluriel et pas session)

[puck78]

Je confirme qu'il n'est pas dynamique, ce paramètre! Ou alors, je n'ai pas trouvé la bonne commande sql...

J'ai changé ce paramètre dans le spfile et j'ai redémarré la base avec un spfile= <mon fichier spfile>.
Je confirme ce que j'ai constaté, à savoir que le nombre de session max indiqué par un "show parameter session" ne correspond pas au nombre que j'ai indiqué dans mon spfile (plus grand).

Ca ne se produit que sur les bases répliquées, donc je suppose qu'il y a un lien mais lequel??

[mboubidi]

t'as modifier dans le spfile avec un vi ? ou scope=spfile ?

[puck78]

J'ai fait beaucoup de choses bancales (des modifications avec vi, oui, pas de scope=xx), dont je ne rappelle plus très bien
Depuis j'ai lu la doc sur le sujet et je comprends mieux les erreurs

Mais bon, le changement de ce paramètre n'était pas important en tant que tel, ce qui m'importe c'est de comprendre pourquoi ce n'est pas la valeur du fichier d'init.
Personne ne touche à ces paramétrages, une intervention humaine est donc exclue.

C'est soit un script qui modifie ce paramètre après le démarrage de la base (mais je ne l'ai pas encore trouvé), soit oracle lui-même...

L'ancien dba m' parlé d'un minimum dans le nombre de session, il parait qu'oracle met au minimum nbr de processus/1,5, même si on indique autre chose dans le fichier d'init.
Je n'ai cependant pas réussi à trouver confirmation de ceci dans la doc.
Est-ce que quelqu'un en a déjà entendu parler?

[Pomalaix]

Pouvez-vous nous donner le résultat de ceci :

Code :

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

1
2
3
4
5
6
col name     format A20
col value     format A20
 
select * from v$version where rownum=1;
 
select name, value from v$parameter where name in ('sessions', 'processes');

[Drawingrom]

Bonjour,

Il y a un minimum pour ce paramètre. Dans la doc de Oracle 11gR2, j'ai pour le paramètre sessions :

Oracle uses the default value of this parameter as its minimum. Values between 1 and
the default do not trigger errors, but Oracle ignores them and uses the default instead.

La valeur par défaut est obtenue par le calcul ci-dessous :

Default value Derived: (1.5 * PROCESSES) + 22

Regardez donc votre paramètre processes.

Pour info, il s'agit de la doc "Refrence", vous pouvez la trouver sur tahiti.oracle.com.

[Pomalaix]

Jusqu'à Oracle 10g, la valeur par défaut de SESSIONS était :
(PROCESSES *1.1) + 5.

En 11.2 (j'ignore ce qu'il en est pour la 11.1), la nouvelle formule qui figure dans la doc n'est pas tout à fait exacte si on veut pinailler, mais ça se joue à 6 ou 7 sessions de différence au maximum, d'après ce que j'ai constaté.

J'avais découvert le sujet il y a peu de temps grâce à cet article : http://hoopercharles.wordpress.com/2...-bug-explains/.

En faisant des tests sur plusieurs dizaines de valeurs, j'ai constaté que :
* SESSIONS va de (PROCESSES * 1.5) + 21.5 à (PROCESSES *1.5) + 29.
* SESSIONS est forcément un multiple de 8
* 5 ou 6 valeurs consécutives de PROCESSES donnent la même valeur pour SESSIONS

Extrait de mes résultats qui illustre ces points :

Code :

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

1
2
3
4
5
6
7
8
9
PROC    SESS     DIFF
1009    1536    22,5
1010    1544    29
1011    1544    27,5
1012    1544    26
1013    1544    24,5
1014    1544    23
1015    1544    21,5
1016    1552    28

[puck78]

Merci de vos réponses, c'est bien ca.

Je suis en 10.2.0.5, donc c'est le calcul (processes*1,1) + 5 qui s'applique.
C'est exactement ca: le paramètre processes est à 380, donc j'obtiens 423 en sessions (alors que mon paramètre d'init est à 335).

Sur les bases non répliquées, le paramètre session est initialisé à plus du minimum oracle, donc je ne voyais pas le problème.

Une dernière question pour la route:
qu'est ce qui se passe si on a nbr processes max * pga_max_size qui est très supérieur à la RAM de la machine?
Dans mon cas, nbr processes max * pga_max_size = 13,5G pour une RAM de 4G

Je ne peux pas toucher à la machine. Je suppose qu'il vaut mieux ne pas diminuer la pga_max_size, sinon c'est toutes les performances qui vont s'en ressentir.
Mais vaut-il mieux limiter le nombre de processes quitte à tomber sur la ORA-00020 (ou 18? enfin bref) ou laisser le système se débrouiller?
Se mettra-t-il à pédaler dans la semoule avec des gros problèmes de perfs pour tout le monde?

[Pomalaix]

... Une dernière question pour la route:
qu'est ce qui se passe si on a nbr processes max * pga_max_size qui est très supérieur à la RAM de la machine?
Dans mon cas, nbr processes max * pga_max_size = 13,5G pour une RAM de 4G

Je ne peux pas toucher à la machine. Je suppose qu'il vaut mieux ne pas diminuer la pga_max_size, sinon c'est toutes les performances qui vont s'en ressentir.
Mais vaut-il mieux limiter le nombre de processes quitte à tomber sur la ORA-00020 (ou 18? enfin bref) ou laisser le système se débrouiller?
Se mettra-t-il à pédaler dans la semoule avec des gros problèmes de perfs pour tout le monde?

Là, il va falloir nous en dire plus, car on sort franchement du cadre de la question gentillette pour la route !
Je suppose que c'est du paramètre caché _PGA_MAX_SIZE que vous parlez.
Qu'est-ce qui vous amène à vous y intéresser spécialement ? Pourquoi donc voulez-vous le multiplier par le nombre de sessions ?

[puck78]

Oui, on sort complètement du sujet...

En fait, c'est une question purement théorique.

Si j'ai bien compris, la pga est la mémoire allouée à chaque process. Donc pga_max_size (paramètre dans le fichier d'init) représente, je pense, la limite max de mémoire qu'il est possible d'allouer à un process.
J'ai eu la curiosité de faire nbr process * pga_max_size (cas théorique avec nbr max de process créé avec chaque process exécutant une requête mal gaulée sur une grosse table).
Le résultat de mon petit calcul rapide étant 13,5 G, je me suis juste demandé comment c'était possible (RAM à 4G) et s'il n'y avait pas une erreur de paramétrage de la base?

Mais bon, si la réponse c'est que c'est pas simple et qu'il faut se former à oracle, je comprends!

[Pomalaix]

En quelques mots largement simplifiés :
PGA_AGGREGATE_TARGET définit une quantité de mémoire PGA mutualisée que les différentes sessions vont se partager selon leur "appétit" respectif.
En temps normal, on se contente de ce paramètre.

PGA_MAX_SIZE n'existe pas. Par contre, il existe un paramètre non documenté _PGA_MAX_SIZE, auquel vous n'avez aucune raison de toucher en temps normal, qui contribue à définir plus finement combien une session individuelle pourra consommer en PGA. (Ca ne veut pas dire "telle quantité pour S1, telle quantité pour S2", mais "une session quelconque pourra consommer jusqu'à n Mo de PGA").

Et ce n'est pas parce qu'on donnerait 100 M pour _PGA_MAX_SIZE, et qu'on aurait 100 sessions, qu'on consommerait immédiatement 10 Go de PGA. Cette limite n'est pas bêtement préallouée ; cela se fait en temps réel selon le besoin véritable, et, me semble-t-il, dans la limite de la PGA disponible.

Mais il reste exact que si on alloue à Oracle plus de mémoire en SGA ou PGA qu'on n'en a réellement au niveau physique, on va au devant de gros problèmes de performances.

[puck78]

Merci c'est beaucoup plus clair!

Je vais aller faire un petit tour du coté des tutoriaux aussi...

Parce que la bonne blague c'est que je suis censée être dba avec une dizaine de base de données en dev, plus une vingtaine de site déployé, sur 5 projets différents à gérer.... Et j'ai eu une formation d'une semaine il y a 2 ans (sans pratique entre temps sinon c'est trop facile!)

Ils sont fous ces romains!

Bonne journée et certainement à bientôt

[Drawingrom]

Parce que la bonne blague c'est que je suis censée être dba avec une dizaine de base de données en dev, plus une vingtaine de site déployé, sur 5 projets différents à gérer.... Et j'ai eu une formation d'une semaine il y a 2 ans (sans pratique entre temps sinon c'est trop facile!)

Bah c'est du dev, au moins vous avez (un peu plus) le droit de faire des bêtises (que sur une base de prod)

Bon courage en tout cas.

[puck78]

Bah c'est du dev, au moins vous avez (un peu plus) le droit de faire des bêtises (que sur une base de prod)

Oui pour les bases de dev
Mais il y a une vingtaine de site déployé (= en prod ).... Bah tant que je ne touche pas aux paramétrages des bases, ca va (partie administration pure que je ne connais pas)!
Ils ont bien des problèmes de perfs sur site, mais comme depuis le début des projets le travail de perfs a toujours été fait du coté du dev et jamais réfléchi coté BDD, je ne m'en fais pas trop. Si l'envie leur en prend enfin, on commencera déjà par mettre des indexs!!

Le seul truc qui me fait réellement flipper en fait, c'est un plantage de base. Je ne sais pas restaurer une base et faire des tests de ce genre me permettant d'acquérir les compétences sur le sujet est une tâche qui n'a pas été planifiée malgré mes demandes....

Enfin bref, c'était juste pour la petite histoire, on peut clôre le post, j'ai ma réponse merci beaucoup!