FAQ: ORA-4030 [Video] [ID 399497.1]

FAQ: ORA-4030 [Video] [ID 399497.1]

---

 修改时间 21-SEP-2011     类型 FAQ     状态 PUBLISHED 

In this Document
  Purpose
     Common Bugs
  Questions and Answers
     What is an ORA-4030?
     What is difference between 4030 and 4031?
     What are the contents of Program Global Area memory?
     Why do I see processes growing larger than the PGA_AGGREGATE_TARGET?
     Can you control the size of a process?
     Can you limit the size of a process?
     What information needs to be gathered to diagnose?
     Why does my code give ORA-4030 when run through listener connection, but not local connection?
     What to look at in RDA?
     What kernel or shell limits need to be checked?
     How to monitor pga usage from within the database?
     How to monitor memory usage from the OS on unix/linux?
     How to monitor memory usage from the OS on MSwindows?
     Why do we still get ORA-4030 or ORA-12500 on MSwindows 32 bit database after adding more ram?
     How to create a heapdump?
     What heapdump level to gather?
     See high amount of 'perm' allocations. When to set 10235 event?
     4G Memory limitation in memory mapped systems using realfree allocator
     Configurations leading to excessive memory usage problems
  References

---

Applies to:

Oracle Server - Enterprise Edition - Version: 8.1.5.0 to 11.2.0.2 - Release: 8.1.5 to 11.2
Information in this document applies to any platform.

Purpose

This article is intended to 

• Help the reader understand causes of the ORA-4030
• Gather the diagnostics needed to narrow down the errors
• Answer some of the common questions asked about ORA-4030
• This is valid not only for ORA-4030 errors, but for any occurrence when the oracle database processes(user or background PGA) are suspected of consuming large amount of memory or potential memory leak. 
  
• You may not get errors and just see high memory usage – ulimit on some platforms/versions no longer cause ORA-4030 to occur
• May get other errors such as ORA-12500
  ora-600 [729] (UGA memory) or ora-600 [730] (SGA or large pool)
  
  

Common Bugs

Notes:
Backport possibilities are only to indicate technical backport or patchset exception may be possible.
Actual availability of backports/PSEs are subject to backport policies as per
Note 209768.1 Pub Database, FMW, and OCS Software Error Correction Support Policy 


Bug
Reported
Fixed
Notes
Details
Bug 3130972
Versions < 10.1.0.2
9.2.0.6/10.1.0.2.0
Backports possible
The realfree allocator on Unix systems imposes a cap at 1Gb of memory per process. This fix relaxes that limit as
in some cases it is desirable to allow a process to use over 1Gb of private memory. If the limit is reached an
ORA-4030 occurs even though the system may have plenty of free memory available and can map that memory into the
process address space.
(The realfree allocator is used on Unix systems where
PGA_AGGREGATE_TARGET is in use)
Workaround:
Configure the system to allow less than 1Gb of memory per process to avoid ORA-4030 errors.
Bug 3565920

Versions < 10.1
9.2.0.8 and higher
Backports no longer
If the shared pool is resized then subsequeunt queries against views based on
X$KSMSP, such as V$SHARED_POOL_RESERVED, result in a memory leak in the cursor work heap which then fails with ORA-4030.
Bug 4475206
Versions < 10.2.0.4

10.2.0.4/11.1.0.6

Backports possible
The PGA memory consumed becomes significantly higher than the value of the
parameter pga_aggregate_target if a query has a very long chain of
hash-join operations. This chain must be right-deep, ie. the build is
performed on a base table and the probe is produced by an hash-join sub-tree.
This is not really a memory leak but excess memory use compared to what
should be used.
Bug 4625938
Versions < 10.2
10.2

10.1.x

A memory leak involving 'peihstdep' and 'PEIDEF' can
occur when TABLE functions are used and JDBC connection pooling is enabled.
Workaround:
Disable connection pooling.
Bug 5118748
Versions < 10.2.0.310.2.0.3/11.1.0.6
Backports possible
ORA 4030 or a memory leak can occur when using a lot of collections in PLSQL. Heapdumps of the "koh-kghu call " heap include multiple chunks of type "pmucp2upkl korfp
Bug 5220562
Versions < 10.2.0.4
10.2.0.4/11.1.0.6

Backports possible

An insert select DML session's process size may increases / ORA-4030
(with sort sub heap chunks) when there is concurrent DDL on the
partitioned tables / objects involved in the DML.
Workaround:
Avoid concurrent execution of the DML and DDL, if possible.
Bug 5389854
Versions < 10.2.0.4
10.2.0.4/11.1.0.6

Backports possible
Execution of a procedure using bulk insert with save exceptions will
consume large amounts of PGA memory during execution. If run with
extremely large number of rows or for a long period of time this can
lead to ORA-4030.
The memory shows up on the "callheap,DARWIN" subheap as "koh-kghu call" memory
Bug 5391505
Versions < 10.2.0.4
10.2.0.4/11.1.0.6
Backports possible
PGA memory may keep on increasing during query parsing and can reach a large
amount (sometimes even over 1G) when OR expansion occurs.
Ultimately ORA-4030 may be encountered as memory runs out.
The memory shows as "perm" space in the "kxs-heap-c" subheap.
Workaround:
alter session set "_no_or_expansion" = true
Bug 5464834
Versions < 10.2.0.4
10.2.0.4/11.1.0.6
Backports possible
ORA-4030 (kxs-heap-c,temporary memory) can occur when using EXPDP
Bug 5866410
Versions < 11
11.1.0.6
Backports possible
Bulk insert in PLSQL can consume a large amount of PGA memory
which can lead to ORA-4030 errors.
A heapdump will show lot of free memory in the free lists which
is not used but instead fresh allocations are made.
Workaround:
Chunk the FORALL loop. Do a hybrid of FOR & FORALL so that the
bulk_rowcount arrays doesnt grow abnormally large
Bug 5947623
Versions >= 10.2.0.1 but < 11.1.0.7
10.2.0.4/11.1.0.7
Backport possible
it is possible for a query to allocate too much memory executing a hash join
over large volumes of data with few distinct join key values.
The impact on 64-bit systems is greater.
This is not really a memory leak as the fix only makes the query to spill to
disk earlier.
Workaround:
set "_pga_max_size"
Bug 6011182
Versions >= 10.2.0.1 but < 10.2.0.4
10.2.0.4
Backport possible
High elapsed time and high memory consumption during parse
can occur for queries with large numbers of query blocks.
If you see high elapsed times and/or memory consumption during parse for a
query, and the query has a large number of query blocks (eg many views,
subqueries or UNION ALL branches) you may be hitting this bug.
For error ORA-04030
The path of the leak is: top call heap -> call heap -> typecheck
largest memory allocations w/comments:
"logdef: qcopCre", "kkoFroAnn: qksf", "frodef: qksfroC"
Bug 6052169
Versions < 11
11.1.0.6
Backports possible
Slave memory grows unbounded and finally fails with ORA-4030.
A heapdump of the memory shows 'Statement Alloc' string.
Bug 6061892
Versions >= 10.2.0.1 but < 10.2.0.4
10.2.0.4/11.1.0.6

Backports possible
It is possible to get error ORA-4030 and ORA-21780 when an application
that drops and/or recreates many plsql packages or top-level
Noteocedures or functions which are used in calls from SQL to PL/SQL.
The leak is found in the heaps:
pga heap -> session heap -> PLS non-lib hp.
Most of the hunks on heap 'PLS non-lib hp' are PEIDEF or peihstdep
Note:
This fix introduces the problem described in bug 6139254
Bug 6408917
Versions < 11
11.1.0.6
Backports possible
Excessive PGA memory consumption can be seen when using ref cursors returned
from Java stored procedures. Ultimately this can lead to out of memory
errors such as:
ORA-29532: java call terminated by uncaught java exception: java.lang.outofmemory
Bug 6414844
Versions < 11.2
11.2
Backports possible to 10.1
memory may be wasted in a subheap using kghu memory allocation.

A heapdump will show free chunks in each extent with a "free" chunk which is
not quite large enough to satisfy a request. This is not really a memory
leak but inefficient use of memory in certain circumstances.
eg:
EXTENT 0 addr=0xb3810008
Chunk b3810010 sz= 16272 free " "  Wasted space
Chunk b3813fa0 sz= 16416 freeable "koh-kghu call "
Chunk b3817fc0 sz= 16416 freeable "koh-kghu call " ds=0xb7a1daf0
Chunk b381bfe0 sz= 16416 freeable "koh-kghu call " ds=0xb7a1daf0