FAQ: ORA-4030 [Video] [ID 399497.1]
2017-01-03 17:13
411 查看
FAQ: ORA-4030 [Video] [ID 399497.1] | ||
修改时间 21-SEP-2011 类型 FAQ 状态 PUBLISHED |
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.2Information 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.3 | 10.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 |
相关文章推荐
- FAQ: ORA-4030 [Video] [ID 399497.1]
- ORA-4031 Common Analysis/Diagnostic Scripts [Video] (文档 ID 430473.1)
- How To Avoid ORA-04030/ORA-12500 In 32 Bit Windows Environment [Video] [ID 373602.1]
- 诊断并解决 ORA-4030 错误 (Doc ID 1548826.1)
- ASMB process grows raising ora-4030 intermittently (Doc ID 735180.1)
- 诊断并解决 ORA-4030 错误 (Doc ID 1548826.1)
- Bug 11805372 - ORA-30009 "not enough memory" for certain CONNECT BY statements [ID 11805372.8]
- Flash Recovery Area - FAQ (文档 ID 833663.1)
- 登陆oracle11g 报错 ORA-01034 ORA-27101 进程 ID: 0 会话 ID: 0 序列号: 0
- ora-00054 , alter system kill session 'id,serial#'
- ORA-03113: 通信通道的文件结尾 进程 ID: 3949 会话 ID: 1 序列号: 3
- 公众号菜单跳转到小程序,页面路径支持带参数pages/videoplay/index?id=443
- ORA-600/ORA-7445/ORA-700 Error Look-up Tool (文档 ID 153788.1)
- ora faq_构架
- ORA-00026: 丢失或无效的会话 ID
- KFED.PL for diagnosing - ORA-15063 ORA-15042 ORA-15020 ORA-15033 (Doc ID 1346190.1)
- liquivid Video Deflickering for Mac(解决视频闪烁工具) v1.0.2破解版
- FAQ系列 | table id问题导致主从复制失败
- ORA-16032 Can not Start Instance via srvctl but via sqlplus is fine [ID 1062071.1]
- 网卡mtu 值不同导致rac 2节点ASM不能同时启动 ORA-27550: Target ID protocol check failed.