Résolution ORA-4031 " incapable d'attribuer x octets de mémoire partagée"
j'ai besoin de quelques conseils sur la façon de diagnostiquer et de résoudre ce problème. Je ne sais pas s'il s'agit d'un simple problème de configuration de serveur ou d'un problème de conception d'application (ou les deux).
une ou deux fois par mois cette base de données Oracle XE signale des erreurs ORA-4031. Il ne désigne pas une partie particulière de la sga de façon cohérente. Un exemple récent est:
ORA-04031: unable to allocate 8208 bytes of shared memory ("large pool","unknown object","sort subheap","sort key")
lorsque cette erreur apparaît, si l'Utilisateur continue à rafraîchir, en cliquant sur des liens différents, ils seront généralement obtenez plus de ces types d'erreurs à des moments différents, puis bientôt ils obtiendront "404 not found" des erreurs de page.
redémarrer la base de données résout habituellement le problème pendant un certain temps, puis un mois ou ainsi plus tard il apparaît à nouveau, mais rarement au même endroit dans le programme (c.-à-d. il ne semble pas lié à une partie particulière du code) (l'erreur d'exemple ci-dessus a été soulevée d'une page Apex qui était le tri 5000+ lignes d'une table).
j'ai essayé d'augmenter sga_max_size à partir de 140M à 256M et espérer que cela aidera les choses. Bien sûr, je ne saurai pas si cela a aidé depuis que j'ai dû redémarrer la base de données pour changer le réglage :)
J'exécute Oracle XE 10.2.0.1.0 sur une Oracle Enterprise Linux 5 box avec 512 Mo de RAM. Le serveur n'exécute que la base de données, Oracle Apex (v3.1.2) et le serveur web Apache. Je l'ai installé avec à peu près tous les paramètres par défaut et ça fonctionne assez bien pour une année. La plupart des problèmes que j'ai été en mesure de résoudre moi-même en réglant le code d'application; il n'est pas utilisé intensivement et n'est pas un système critique pour l'entreprise.
ce sont certains paramètres actuels je pense que peut-être utiles:
pga_aggregate_target 41,943,040
sga_max_size 268,435,456
sga_target 146,800,640
shared_pool_reserved_size 5,452,595
shared_pool_size 104,857,600
Si c'est toute l'aide ici est la SGA tailles:
Total System Global Area 268435456 bytes
Fixed Size 1258392 bytes
Variable Size 251661416 bytes
Database Buffers 12582912 bytes
Redo Buffers 2932736 bytes
6 réponses
même si vous utilisez L'ASMM, vous pouvez définir une taille minimale pour la grande piscine (MMAN ne la réduira pas en dessous de cette valeur). Vous pouvez aussi essayer d'épingler Certains objets et d'augmenter SGA_TARGET.
N'oubliez pas la fragmentation. Si vous avez beaucoup de trafic, vos piscines peuvent être fragmentées et même si vous avez plusieurs Mo gratuits, il ne pourrait pas y avoir de bloc plus grand que 4KB. Vérifiez la taille du plus grand bloc libre avec une requête comme:
select
'0 (<140)' BUCKET, KSMCHCLS, KSMCHIDX,
10*trunc(KSMCHSIZ/10) "From",
count(*) "Count" ,
max(KSMCHSIZ) "Biggest",
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ<140
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 10*trunc(KSMCHSIZ/10)
UNION ALL
select
'1 (140-267)' BUCKET,
KSMCHCLS,
KSMCHIDX,
20*trunc(KSMCHSIZ/20) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 140 and 267
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 20*trunc(KSMCHSIZ/20)
UNION ALL
select
'2 (268-523)' BUCKET,
KSMCHCLS,
KSMCHIDX,
50*trunc(KSMCHSIZ/50) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 268 and 523
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 50*trunc(KSMCHSIZ/50)
UNION ALL
select
'3-5 (524-4107)' BUCKET,
KSMCHCLS,
KSMCHIDX,
500*trunc(KSMCHSIZ/500) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ between 524 and 4107
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 500*trunc(KSMCHSIZ/500)
UNION ALL
select
'6+ (4108+)' BUCKET,
KSMCHCLS,
KSMCHIDX,
1000*trunc(KSMCHSIZ/1000) ,
count(*) ,
max(KSMCHSIZ) ,
trunc(avg(KSMCHSIZ)) "AvgSize",
trunc(sum(KSMCHSIZ)) "Total"
from
x$ksmsp
where
KSMCHSIZ >= 4108
and
KSMCHCLS='free'
group by
KSMCHCLS, KSMCHIDX, 1000*trunc(KSMCHSIZ/1000);
toutes les réponses actuelles traitent le symptôme (épuisement de la mémoire partagée), et non le problème, qui n'utilise probablement pas les variables bind dans vos requêtes sql \ JDBC, même s'il ne semble pas nécessaire de le faire. En passant des requêtes sans variables bind, Oracle" analyse " la requête à chaque fois, en déterminant son plan d'exécution, etc.
https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::p11_question_id:528893984337
Quelques extraits à partir du lien ci-dessus:
"Java supporte les variables bind, vos développeurs doivent commencer à utiliser les déclarations préparées et les entrées de bind. Si vous voulez que votre système finisse par se mettre à l'échelle au-delà de 3 ou 4 utilisateurs par exemple, vous allez le faire maintenant (corriger le code). Il n'est pas quelque chose à penser, c'est quelque chose que vous DEVEZ faire. Un des effets secondaires de vos problèmes de piscine commune vont pratiquement disparaître. Qui est la cause de racine. "
"Le chemin de l'Oracle pool partagé (une structure de données de mémoire partagée très importante)) l'opération est basée sur des développeurs utilisant des variables de bind."
" Lier les variables sont DONC MASSIVEMENT important -- je ne peut, en aucune manière, la forme ou la forme SURESTIMER leur importance. "
Les suivantes ne sont pas nécessaires, car ils-elles pas réparer l'erreur:
- 1 ps-ef / grep oracle
- trouver le smon et tuer le pid pour lui
- SQL> startup mount SQL>
- Créer un pfile de spfile;
redémarrer la base de données va vider votre piscine et cela résout un effet pas le problème.
fixez votre grand_pool de sorte qu'il ne peut pas aller plus bas qu'un certain point ou ajouter de la mémoire et définir un max plus élevé mémoire.
Erreur: ORA-04031: incapable d'allouer 4064 octets de mémoire partagée ("pool partagé", " select increment$, minvalue, M...","sga tas(3,0)","kglsim tas")
Solution: by nepasoft nepal
1 ps-ef|grep oracle
2 Trouvez le smon et tuez le pid pour lui
3 SQL> mount startup
l'instance ORACLE a commencé.
Total du Système Global de la Zone 4831838208 octets Taille fixe 2027320 octets Taille Variable 4764729544 octet Tampons de base de données 50331648 octets Tampons Redo 14749696 octets Base de données monté. SQL>
4 SQL> alter system set shared_pool_size=100M scope=spfile;
système modifié.
5 SQL> shutdown immediate
ORA-01109: base de données de ne pas ouvrir
Base de données démontée. L'instance D'ORACLE s'est éteinte.
6 SQL> startup
l'instance ORACLE a commencé.
Total Du Système Global De La Zone 4831838208 octets Taille fixe 2027320 octets De Taille Variable 4764729544 octets Tampons de base de données 50331648 octets Tampons Redo 14749696 octets Base de données monté. Base de données ouverte.
7 SQL> create pfile from spfile;
fichier créé.
résolu
c'est Oracle bug, fuite de mémoire dans shared_pool, très probablement db gérant beaucoup de partitions. Solution: à mon avis, patch n'existe pas, vérifiez avec le support d'oracle. Vous pouvez essayer avec subpools ou en (de)able AMM ...