Risoluzione di ORA-4031 "impossibile allocare x byte di memoria condivisa"

Question

Ho bisogno di alcuni suggerimenti su come diagnosticare e risolvere questo problema. Non so se si tratta di un semplice problema di configurazione del server o di un problema di progettazione dell'applicazione (o di entrambi).

Una volta o due volte ogni qualche mese questo database Oracle XE segnala errori ORA-4031. Non punta a nessuna parte particolare della sga in modo coerente. Un esempio recente è:

ORA-04031: unable to allocate 8208 bytes of shared memory ("large pool","unknown object","sort subheap","sort key")

Quando questo errore viene in su, se l'utente continua a rinfrescante, cliccando su diversi collegamenti, faranno in genere ottenere più di questi tipi di errori in tempi diversi, allora presto' Otterremo gli errori di pagina "404 non trovati".

Il riavvio del database in genere risolve il problema per un po ', quindi un mese o giù di lì torna di nuovo, ma raramente nella stessa posizione nel programma (cioè non sembra collegato a una particolare parte di codice) (l'errore di esempio precedente è stato generato da una pagina Apex che stava ordinando 5000+ righe da una tabella).

Ho provato ad aumentare sga_max_size da 140 M a 256 M e spero che questo possa aiutare le cose. Naturalmente, non saprò se questo ha aiutato dal momento che ho dovuto riavviare il database per modificare l'impostazione :)

Sto eseguendo Oracle XE 10.2.0.1.0 su una scatola Oracle Enterprise Linux 5 con 512 MB di RAM. Il server esegue solo il database, Oracle Apex (v3.1.2) e il server Web Apache. L'ho installato con praticamente tutti i parametri predefiniti ed è stato eseguito abbastanza bene per circa un anno. La maggior parte dei problemi sono riuscito a risolvere me stesso sintonizzando il codice dell'applicazione; non è utilizzato in modo intensivo e non è un sistema aziendale critico.

Queste sono alcune impostazioni correnti penso possa essere rilevante:

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 

Se si tratta di alcun aiuto, ecco le attuali dimensioni SGA:

Total System Global Area 268435456 bytes 
Fixed Size     1258392 bytes 
Variable Size    251661416 bytes 
Database Buffers   12582912 bytes 
Redo Buffers    2932736 bytes 

Answer 1

Anche se si sta utilizzando ASMM, è possibile impostare un dimensione minima per il grande pool (MMAN non lo ridurrà al di sotto di tale valore). Puoi anche provare a appuntare alcuni oggetti e aumentare SGA_TARGET.

Answer 2

Non dimenticare la frammentazione. Se si ha molto traffico, i pool possono essere frammentati e anche se sono disponibili diversi MB liberi, non potrebbe esserci blocco maggiore di 4KB. Controllare le dimensioni del più grande blocco con una query del tipo:

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); 

Code from

Answer 3

Errore: ORA-04031: in grado di allocare 4064 byte di memoria condivisa ("piscina in comune", "selezionare $ incremento , minvalue, m ... "" mucchio SGA (3,0)", "mucchio kglsim")

Solution: by nepasoft nepal 

1 ps -ef | grep oracolo

2 Individuare lo SMON e uccidere il pid per esso

3 SQL> mount all'avvio

istanza ORACLE iniziato.

totale del sistema Global Area 4.831.838,208 mila byte Fixed Size 2.027.320 byte Formato variabile 4.764.729,544 mila byte buffer di database 50.331.648 byte Redo Buffer 14.749.696 byte Database montato. SQL>

4 SQL> set di sistema alter shared_pool_size = 100M scope = spfile;

Sistema alterato.

5 SQL> immediato arresto

ORA-01109: database non aprire

database smontato. L'istanza di ORACLE è stata chiusa.

6 SQL> avvio

L'istanza di ORACLE è stata avviata.

totale del sistema Global Area 4.831.838,208 mila byte Fixed Size 2.027.320 byte Formato variabile 4.764.729,544 mila byte buffer di database 50.331.648 byte Redo Buffer 14.749.696 byte Database montato. Database aperto.

7 SQL> creare pfile da spfile;

File creato.

risolto

Answer 4

Questo è Oracle bug, perdita di memoria in shared_pool, molto probabilmente db gestire un sacco di partizioni. Soluzione: Secondo me la patch non esiste, verificare con il supporto Oracle. Si può provare con sotto pool o EN (de) AMM in grado ...

Answer 5

Il seguenti non sono necessari in quanto essi non correggere l'errore:

1. 1 ps -ef | grep oracolo
2. Trova la smon e uccidi il pid per esso
3. SQL> SQL di avvio SQL>
4. Creare pfile da spfile;

Il riavvio del database farà svuotare il pool e questo risolve un problema, non il problema.

Fissare il proprio large_pool in modo che non possa andare più in basso di un certo punto o aggiungere memoria e impostare una memoria massima più alta.

Answer 6

Tutte le risposte correnti riguardano il sintomo (esaurimento del pool di memoria condiviso) e non il problema, che probabilmente non utilizza le variabili di collegamento nelle query sql \ JDBC, anche quando non sembra necessario. Passando le query senza variabili di binding, Oracle cerca di "analizzare" la query ogni volta, determinandone il piano di esecuzione, ecc.

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::p11_question_id:528893984337

alcuni frammenti dal link qui sopra:.

"Java supporta variabili di bind, gli sviluppatori devono iniziare a utilizzare le dichiarazioni preparate e legare gli ingressi in esso Se si desidera che il sistema di scalare in ultima analisi, al di là di dire su 3 o 4 utenti - lo farai adesso (correggi il codice). Non è qualcosa a cui pensare, è qualcosa che DEVI fare. Un effetto collaterale di questo: i problemi del pool condiviso spariranno praticamente. la causa principale. "

" Il modo in cui l'OracleIl pool condiviso 210 (una struttura di dati di memoria condivisa molto importante) opera è previsto per gli sviluppatori che utilizzano variabili di bind. "

"variabili di bind sono così massicciamente importante - non posso in alcun modo o forma sopravvalutare la loro importanza."