Diagnosing ORA-04031 on Oracle9iR2

Question

Hi
We're running an Oracle9iR2 (9.2.0.6) database on Red Hat Enterprise Linux 4.0 (IA32). The database is used for development and testing. It's been running ok until recently users started getting the following error when trying to connect to the database:
ORA-04031: unable to allocate 17168 bytes of shared memory ("shared pool","unknown object","sga heap(1,0)","session param values")
What's changed during the last weeks is that we've installed Oracle10gR2 and the Oracle Calendar server on the machine, and added a about 10-20 new user accounts.
The server was originally running in dedicated server mode until i noticed there were 115 Oracle processes running on the server at one moment. The database typically has large number of connections which are idle most of the time. I changed it to shared server mode in order to avoid the overhead of having lots of server processes which are doing nothing most of the time.
I also increased the shared_pool_size and large_pool_size on the server but i'm still seeing ORA-04031 errors in trace files. How do i determine whether the cause is shared or large pool? How do i determine the right sizes for these pools? The traces include heap dumps for large pool.
The SQL query appearing in the trace files cursor name section is just one type of SQL query in most of the cases. How can i debug shared memory usage for a particular SQL query so that i can try and modify it to a more memory economic direction?
br. aspa

Answer 1

Hi,
If you have access to metalink, I advise you to read 146599.1 Diagnosing and Resolving Error ORA-04031.
The SQL query appearing in the trace files cursor name section is just one type of SQL
query in most of the cases. How can i debug shared memory usage for a particular SQL
query so that i can try and modify it to a more memory economic direction?The following SQL can show you statements with literal values or candidates to include bind variables:
SELECT substr(sql_text,1,40) "SQL",
count(*) ,
sum(executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY substr(sql_text,1,40)
HAVING count(*) > 30
ORDER BY 2;Note: The number "30" in the having section of the statement can be adjusted as needed to get more detailed information.
There is a fixed table called x$ksmlru that tracks allocations in the shared pool that cause other objects in the shared pool to be aged out. This fixed table can be used to identify what is causing the large allocation.
SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;Note : This view can only be queried by connected as the SYS.
How have you RAM ?
Since your last install, perhaps your RAM is not sufficient any more ?
Check your memory occupation.
Nicolas.
How do i determine whether the cause is shared or large pool? If there is no free memory into large pool left when a request is made then an ORA-4031 will be signalled similar to this : ORA-04031: unable to allocate XXXX bytes of shared memory
("large pool","unknown object","session heap","frame")
Message was edited by:
N. Gasparotto