Erreur ORA-04031 sur connexion sqlplus

[bigorj]

Bonjour a tous,

J'ai un probleme de connexion sur une base Oracle sur Solaris.

J'ai la version 9.2.0 installée et lorsque que je connecte en ligne de commande directement sur oracle (en sqlplus), la premiere connexion fonctionne tres bien mais je n'arrive pas a lancer une deuxieme connexion sans avoir l'erreur 04031.

J'ai absolument besoin d'au moins 2 connexions simultanées pour pouvoir d'un coté interroger/administrer la base et de la superviser.

j'ai verifié le shared_pool_size qui est plus que suffisant et j'avoue ne pas trouver ou est l'erreur.
J'ai parcouru plusieurs post sur ce type d'erreur mais aucun ne semble correspondre a cette erreur qui, a mon avis, est la partie emergeante de l'iceberg...
Je ne suis malheureusement pas dba... (snif), mais je sent que je vais me faire une petite formation sur le sujet...

Je pense que c'est juste un probleme de conf mais lequel???

voici mon initORACLE_SID.ora :

db_files = 80 # SMALL


db_file_multiblock_read_count = 8 # SMALL
##shared_pool_size = 10000000 # INITIAL
shared_pool_size = 15000000 # INITIAL

log_checkpoint_interval = 10000
log_checkpoint_timeout = 1800

processes = 100 # LARGE

log_buffer = 163840 # INITIAL
compatible = "9.2.0"

max_enabled_roles = 25
sessions=50

optimizer_index_caching=90
optimizer_index_cost_adj=10

db_cache_size = 100M
undo_management=auto

NLS_LANGUAGE = 'AMERICAN'
NLS_TERRITORY = 'AMERICA'
remote_login_passwordfile=exclusive

Merci d'avance de votre aide sur le sujet.

@++

[orafrance]

http://ora-04031.ora-code.com/

c'est pourtant clair, la SGA est trop petite

15Mo ça me parait vraiment TRES petit

Dis moi, c'est normal d'avoir setté les paramètres optimizer_index_* ?

[bigorj]

Rapide la réponse !!! merci

Pour l'optimizer_index*, n'ayant pas un envirronnement fixe, nous avons choisi de les mettres a ces valeurs car je ne suis pas censé etre le seul a travailler dessus (pour l'instant c'est le cas mais dans un avenir proche). et le choix de 90 et non de 100 (valeur par defaut) permet de diminuer le cout des requetes (si je ne me trompe pas, n'etant pas un grand connaisseur )

Sinon, j'ai une autre base oracle avec le SDA (enfin le shared_pool_size) a 10Mo et je ne rencontre pas ce type de probleme.

Je vais verifier pq j'avoue, je connais pas grand chose a Oracle (j'essaie d'ameliorrer cette lacune), mais j'ai l'impression que mes dba y connaissent encore moins ...

[orafrance]

Envoyé par bigorj

et le choix de 90 et non de 100 (valeur par defaut) permet de diminuer le cout des requetes (si je ne me trompe pas, n'etant pas un grand connaisseur )

C'est exactement ce que je voulais voir

Si tu le mets à 10 ça va encore diminuer le coût si tu veux

Ces paramètres ont un impacte très fort sur l'optimiseur. optimizer_index_cost_adj=10 indique à Oracle que le cout d'un index est égale à 10% du coût d'un accés sur la table... autant dire que ce n'est jamais vrai. Il convient de mesurer réellement les accés disques avant de paramètrer ces valeurs. Ca sert notamment l'optimiseur lorsque le plan d'exécution a tendance à favoriser les FTS mais personnellement, je préfère l'indiquer au niveau session.

Pour info : http://www.dba-oracle.com/art_so_opt...ex_caching.htm

Il faut noter que les stats system permettent de s'affranchir de ces paramètres puisqu'Oracle calcul lui-même les stats de la machine et du stockage

Envoyé par bigorj

mais j'ai l'impression que mes dba y connaissent ncore moins ...

ha bon ?

à propos de la SGA : http://oracle.developpez.com/guide/a...archiinstance/

[bigorj]

Ok, je vais voir pour la config de l'optimizer, le mieux serait de laisser Oracle config automatiquement alors?

Par contre, pour la probleme de SDA, sur mon autre instance Oracle (autre becane), j'ai donc le shared_pool_size a 10 Mo et je lance au moins 5 instances (si ce n'est plus) simultanement sans erreur...

Je trouve ca etrange qd meme... je vais voir s'il n'y a pas un package type dbms_shared_pool d'installer, ce qui pourrait expliqué en partie la difference...

[orafrance]

ça dépend surtout de ce qui est monté en mémoire, ça peut être très différent d'une base à l'autre

[bigorj]

ben, le probleme c'est que ce sont 2 bases quasi identique...

Les tables/données chargées sont les memes...

Merci en tout cas de la rapidité des tes reponses

[orafrance]

je compléte ma réponse

"ça dépend surtout de ce qui est monté en mémoire par chacune des sessions"

[bigorj]

ha d'accord

et comment je peu verifier ce qu'une session charge en memoire ?

[orafrance]

je te propose de lire le tutoriel que j'ai cité plus haut