ORA-04030错误
ORA-04030错误
诊断并解决 ORA-4030 错误 (文档 ID 1548826.1)
适用于:
Oracle Database - Enterprise Edition - 版本 8.1.7.4 和更高版本本文档所含信息适用于所有平台
用途
如何诊断 ORA-4030 错误
排错步骤
诊断并解决 ORA-4030 错误
ORA-4030 意味着什么？
你可能在日志文件中或者屏幕上看到这个错误: ORA-04030 'out of process memory when trying to allocate %s bytes (%s,%s)'
该错误意味着 Oracle Server 进程无法从操作系统分配更多内存。该内存由 PGA（Program Global Area）组成，其内容取决于服务器配置。对于专用的服务器进程，内存包含堆栈以及用于保存用户会话数据、游标信息和排序区的 UGA（User Global Area）。在多线程配置中（共享服务器），UGA 被分配在 SGA（System Global Area）中，所以在这种配置下 UGA 不是造成 ORA-4030 错误的原因。
因此，ORA-4030 表示进程需要更多内存（堆栈 UGA 或 PGA）来执行其任务。
是什么导致了该错误？
由于发生了这个错误，您因此无法从操作系统分配内存。这个错误可能是进程本身导致的，例如进程需要过多的内存，或者一些其他原因导致操作系统内存被耗尽，例如 SGA 太大或系统虚拟内存（物理内存 + 交换空间）中要容纳的进程过多。许多操作系统会对单个进程能够获取的内存量加以限制，以便自我保护。所以我们就会有下列问题：
问题：
-
是否仍然有足够的可用内存？
-
是否设置了操作系统限制？
-
是否设置了 Oracle 限制？
-
哪个进程需要的内存过多？
-
如何收集有关进程实际正在执行的任务的信息？
下面我们将讨论这些内容。
其他主题：
- 有关避免此错误的一般建议
是否仍然有足够的可用内存？
要回答这个问题，我们需要使用操作系统特定的工具来检查内存使用情况。
-
OpenVMS 系统：show memory 会提供关于物理内存和页面文件使用情况的信息：
Physical Memory Usage (pages): Total Free In Use Modified
Main Memory (256.00Mb) 32768 24849 7500 419
.....
Paging File Usage (blocks): Free Reservable Total
DISK$BOBBIEAXPSYS:[SYS0.SYSEXE]SWAPFILE.SYS 30720 30720 39936
DISK$BOBBIEAXPSYS:[SYS0.SYSEXE]PAGEFILE.SYS 226160 201088 249984
DISK$BOBBIE_USER3:[SYS0.PAGEFILE]PAGEFILE.SYS 462224 405296 499968
作为一般准则，页面文件中的可用空间总和应不低于整个空间总和的一半。
交换文件应几乎不使用，可用空间的大小应大致等于总空间的大小。 -
Windows 系统：在“任务管理器”的性能选项卡中检查内存使用情况。
-
Unix 系统：每种 unix 系统通常都有自己的工具来检查系统上的全局内存使用情况，如 top、vmstat……并且在不同的 OS 上，内存管理的运作方式各不相同。
-
-
top 通常会显示物理内存和交换空间的统计信息
-
swapon -s 显示交换空间使用情况
-
vmstat 显示可用物理内存
-
Linux 上的 top 输出示例：
top - 10:17:09 up 1:27, 4 users, load average: 0.07, 0.12, 0.05
Tasks: 110 total, 4 running, 105 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.3% user, 1.6% system, 0.0% nice, 98.0% idle
Mem: 1033012k total, 452520k used, 580492k free, 59440k buffers
Swap: 1052248k total, 0k used, 1052248k free, 169192k cached
.....
如果有足够的内存可用，请检查操作系统是否存在强制限制。如果内存已被耗尽，我们就需要找出内存被用到了哪些地方。
是否设置了操作系统限制？
如果似乎仍剩余大量的虚拟内存，那么有可能是我们需要使用的内存量是不被允许的。下面的步骤可以用来检查由操作系统实施的限制。
-
OpenVMS 系统：若要检查您可以使用的物理内存量，请使用授权工具来检查 working set 配额和页面文件配额。请参阅 OpenVMS 部分，了解使用了哪些配额以及如何修改配额。根据进程类型以及启动的方式，其所用的配额可能不是 Oracle中的那部分配额。show process/id=/quota 会显示某个进程还剩余多少配额。
UAF> show oracle7
Username: ORACLE7 Owner: Oracle7 DBA
Account: SUPPORT UIC: [200,2] ([SUPPORT,ORACLE7])
CLI: DCL Tables: DCLTABLES
Default: DISK$BOBBIE_USER1:[ORACLE7]
LGICMD: LOGIN
Flags:
Primary days: Mon Tue Wed Thu Fri
Secondary days: Sat Sun
No access restrictions
Expiration: (none) Pwdminimum: 6 Login Fails: 0
Pwdlifetime: (none) Pwdchange: 3-DEC-1997 15:38
Last Login: 27-MAY-2003 14:54 (interactive), 26-MAY-2003 16:15 (non-interactive)
Maxjobs: 0 Fillm: 1200 Bytlm: 180000
Maxacctjobs: 0 Shrfillm: 0 Pbytlm: 0
Maxdetach: 0 BIOlm: 500 JTquota: 8192
Prclm: 20 DIOlm: 500 WSdef: 2500
Prio: 4 ASTlm: 4000 WSquo: 4096
Queprio: 0 TQElm: 4000 WSextent: 30000
CPU: (none) Enqlm: 18000 Pgflquo: 750000
Authorized Privileges: .....
$ sho proc/id=20200139/quota
24-JUN-2003 12:30:54.39 User: ORACLE7 Process ID: 20200139
Node: BOBBIE Process name: "ORA_BOB901_PMON"
Process Quotas:
Account name: SUPPORT
CPU limit: Infinite Direct I/O limit: 100
Buffered I/O byte count quota: 9994816 Buffered I/O limit: 100
Timer queue entry quota: 99 Open file quota: 29997
Paging file quota: 145968 Subprocess quota: 10
Default page fault cluster: 64 AST quota: 496
Enqueue quota: 49995 Shared file limit: 0
Max detached processes: 0 Max active jobs: - Windows 系统：在 Microsoft Windows 操作系统中，Oracle 各个进程是在一个进程中以多线程实施的。对于 32 位的系统，可寻址的内存量为 2Gb（包括堆栈、PGA 和 SGA）。此限制可以增加到 3Gb 或更高。有关更多信息，请参阅“Oracle Database and the Windows NT memory architecture, Technical Bulletin”。对于 64 位的系统这个限制就高多了。Oracle 进程使用的总内存（不包括进程堆栈和代码）可通过此查询进行确定。
-
Unix 系统：使用 limit/ulimit shell builtin 命令。请注意，unlimited 的不一定意味着不受限制，实际也可能是基于历史原因的限制，例如 2Gb。推荐基于真实需要的量进行设置：
Linux 输出示例：
aroelant@aroelant-be:~> ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited
有的问题可能是因为限制设置得过低造成的，所以需要进行相应的增加。也有的问题可能是由于我们需要使用的太多造成的。
请注意：其他 OS 参数设置（例如 maxuproc）可能会导致问题
例如，”ORA-4030 (QERHJ HASH-JOI,KLLCQAS:KLLSLTBA)”
Status: 92,Closed, Not a Bug
***来自于 bug - "Increased MAXUPROC from 1000 to 2000, restarted the listener and ORA-4030 errors were resolved"
是否设置了 Oracle 限制？
从 Oracle Version 9i 开始我们引入了参数 PGA_AGGREGATE_TARGET，该参数尝试限制一个实例可以分配的 PGA 总量。“Automatic PGA Memory Managment”部分提供了关于此问题的更多信息。以下查询可用于查找分配给所有会话的 PGA 区的内存总量：
SQL> select
sum(value)/1024/1024 Mb
from
v$sesstat s, v$statname n
where
n.STATISTIC# = s.STATISTIC# and
name = 'session pga memory';
哪个进程需要的内存过多？
一些操作会需要大量的进程内存，例如大型的 PL/SQL 表或大量的排序操作。在这些情况下，在出现错误 ORA-4030 之前，进程将会运行一段时间，所以我们有希望在这段时间内能找出内存分配的位置和原因。您可以使用以下查询来查找从 Oracle 角度看来所用于 Oracle 进程的 PGA 和 UGA 大小。
SQL> col name format a30
SQL> select
sid,name,value
from
v$statname n,v$sesstat s
where
n.STATISTIC# = s.STATISTIC# and
name like 'session%memory%'
order by 3 asc;
此查询会显示列表中最占内存的进程。
通常，从操作系统的角度来确认进程内存使用情况，是一个好办法。毕竟，使用过多内存的不一定是 Oracle Server 进程。通常，对于服务器进程而言，Oracle 和操作系统之间基本都可以就内存的使用情况达成一致。通过以下命令，您可以查找操作系统中进程的内存使用情况。
- OpenVMS 系统：show system 将显示关于进程和资源的总体使用情况。频繁调用页面失败的进程通常会使用大量虚拟内存。“Pages”列指示物理页的使用情况。show process/continious 命令显示物理（工作集）和虚拟内存的使用情况。
$ show system/pag OpenVMS V7.2-1 on node BOBBIE 13-JUN-2003 09:56:30.44 Uptime 17 18:58:18
Pid Process Name State Pri I/O CPU Page flts Pages
20200101 SWAPPER HIB 16 0 0 00:00:02.45 0 0
20200106 CLUSTER_SERVER HIB 13 104 0 00:00:00.03 87 104
20200107 CONFIGURE HIB 10 21 0 00:00:00.06 77 17
$ sho process/id=xxx/cont:
Process AROELANT 10:00:53
State CUR Working set 131
Cur/base priority 6/4 Virtual pages 11714
Current PC 800D9B28 CPU time 0 00:00:01.28
Current PSL 00000003 Direct I/O 178
Current user SP 7A5227F0 Buffered I/O 962
PID 20200469 Page faults 1312
UIC [SUPPORT,AROELANT] Event flags C0000003
C0000000 - Windows 系统：在 Microsoft windows 系统中， Oracle 是通过在单个进程中使用多个线程来实施的。直到现在，尚未找到可以查看每个线程的内存使用情况的方法。但是，我们可以检查 Oracle 和操作系统是否就 Oracle 所使用的内存达成一致。从操作系统的角度看，我们可以使用任务管理器。单击查看按钮并选择选择列(S)...，确保已选中虚拟内存大小(V)。oracle.exe 的虚拟内存大小 列中显示的大小应与 SGA、总 PGA 内存以及进程堆栈和代码大小的总和相同。以下查询可用于获取 Oracle 所查看的内存大小，但是不包括进程堆栈和代码大小：
SQL> select
sum(bytes)/1024/1024 Mb
from (
select
bytes
from
v$sgastat
union
select
value bytes
from
v$sesstat s, v$statname n
where
n.STATISTIC# = s.STATISTIC# and
n.name = 'session pga memory'
);
MB
----------
517.296406在我的系统中，这个值要比通过任务管理器所看到的 VM值小约 30 Mb。
当您确定 Oracle 就是那个正在大量使用内存的进程时，此查询会显示使用内存最多的会话 - Unix 系统：top 是一个非常有用的工具，您可以自定义列显示和基于关键字排序。ps 命令在大部分系统上都可用，但具体使用方法不尽相同。例如，在 Linux 系统上，“ps -AF --sort resident”会列出具有最大驻留集大小的所有进程。另请参阅“UNIX: Determining the Size of an Oracle Process”。
如何收集有关进程实际正在执行的任务的信息
这部分将只讨论 Oracle Server 进程。通过前面介绍的方法，您应该可以确定一个或多个 Oracle Server 进程导致了内存消耗。请记住，并非总是出现 ORA-4030 的进程导致了内存消耗，这个进程可能只是无法申请到需要的内存而已。
对于不断增加内存使用的进程，我们可以在其运行时进行查看以下方面的信息：
- 您可以使用以下查询检查 v$sqlarea 从而找到进程正在执行的 SQL：
SQL> select
sql_text
from
v$sqlarea a, v$session s
where a.address = s.sql_address and
s.sid =;
- 我们可以做heapdump，并将结果提交给 Oracle 技术支持：
SQL> select PID from v$process p, v$session s where p.addr=s.paddr and sid=;
SQL> oradebug setorapid
SQL> oradebug unlimit
SQL> oradebug dump errorstack 3
SQL> oradebug dump heapdump 536870917
SQL> oradebug tracefile_name (shows the path and filename information)
SQL> oradebug close_trace
如果问题间歇出现或某一进程由于报错太快而导致无法进行检查，且这个进程最有可能是内存消耗的原因，那么，在进程发生错误时我们可以使用以下事件来获取 heapdump：
SQL> alter session set events '4030 trace name heapdump level 536870917';
或者在数据库初始化文件中设置此事件并重新启动实例。
- init.ora: event="4030 trace name heapdump level 536870917"
- spfile: 运行: SQL> ALTER SYSTEM SET EVENT='4030 trace name heapdump level 536870917' scope=spfile;
对于 低于 9.2.0.5 的版本，请使用级别 5，而非级别 536870917。
Oracle技术支持工程师可使用该heapdump查找过多内存分配的原因。
有关避免此错误的一般建议
-
如上所述，一些操作需要大量的内存。对于排序问题，减少 SORT_AREA_SIZE 会有所帮助。Oracle Server 进程会将 PGA 中的 SORT_AREA_SIZE 字节分配给排序操作。如果完成搜索需要更多内存，服务器进程将会使用temporary segment。这意味着，减少 SORT_AREA_SIZE 会对需要大量排序操作的查询性能产生影响。
-
对于 9i 及更高版本，通过将参数 WORKAREA_SIZE_POLICY 设置为 AUTO，以及在初始化文件中指定 PGA_AGGREGATE_TARGET 的大小，即可启用自动 SQL 执行内存管理功能。使用自动 PGA 内存管理将有助于减少发生 ORA-4030 错误的可能性。请注意，OpenVMS 操作系统在Oracle 9i版本上不支持 PGA_AGGREGATE_TARGET，但是在 Oracle 10g 版本上是支持的。有关更多详细信息，请参阅以下文档：
"Performance Issues After Increasing Workload",
"Automatic PGA Memory Managment",
"Top Oracle 9i init.ora Parameters Affecting Performance" -
PL/SQL 程序也可分配大量内存，因此可能需要重写应用程序的某些部分。尽管 PL/SQL 表非常容易使用，但它确实需要在 PGA 中分配内存。
-
查看 optimizer 策略，一些访问路径可能会因排序操作、较多行上的函数使用等原因而需要更多内存。
-
在某些操作系统上（例如 Microsoft Windows），可能要降低 SGA 的大小以便于 PGA 获得更大的内存。
-
确保您的操作系统和 Oracle 限制设置合理。
-
确保有足够的可用内存（物理内存和交换空间）。
参考
NOTE:199746.1 - How to Resolve ORA-4030 Errors on UNIXNOTE:46001.1 - Oracle Database and the Windows NT memory architecture, Technical Bulletin
NOTE:116076.1 - Tackling ORA-4030 on Windows 32-bit Operating System
NOTE:67033.1 - OpenVMS: How Background Process Quotas are Set for Oracle RDBMS
NOTE:123754.1 - AIX: Determining Oracle Memory Usage On AIX
NOTE:174555.1 - UNIX: Determining the Size of an Oracle Process
NOTE:1088267.1 - Master Note for Diagnosing OS Memory Problems and ORA-4030
How to Resolve ORA-4030 Errors on UNIX (文档 ID 199746.1)
APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.1.7.0 and laterGeneric UNIX
***Checked for relevance on 27-Jan-2016***
PURPOSE
Provide assistance in resolving ORA-4030 errors on UNIX systems.
SCOPE
This document is useful for DBA's and System Administrators tasked with resolving an ORA-4030 error.
***Checked for relevance 17-Aug-2014***
DETAILS
BACKGROUND
The ORA-4030 error is caused when an Oracle process(while doing work on behalf of a client program) requests additional memory from the operating system, but the operating system cannot accommodate the request. This can occur because the operating system does not have enough physical memory or swap available for the process, the OS is configured to limit the amount of memory available for UNIX processes or an actual Oracle BUG has been encountered.
HOW TO RESOLVE THE ORA-4030
- Upload your files to the ORA-4030 Troubleshooting Tool. See the following note for details: <1521926.1> ORA-4030 Troubleshooting Tool
- Reduce the PGA (Program Global Area) for the client process encountering the error. This is valid if the database is not configured with MTS (Multi Threaded Server) or Shared Servers.
For Oracle 8i and below the major portion of ORA-4030 instances can be solved by reducing the SORT_AREA_SIZE for the sessions. This will lessen the demand that the process places on physical memory. SORT_AREA_SIZE can be modified by the 'alter session' command but persistent changes must be recorded in the init.ora. See the Oracle Reference guide available on your Online Generic Documentation CD-ROM for more information on the 'sort_area_size' parameter.
For Oracle 9i and up, the PGA can be sized using the PGA_AGGREGATE_TARGET parameter set in the init.ora or spfile.ora (See Document153367.1 - Init.ora Parameter "PGA_AGGREGATE_TARGET" Reference Note and 146577.1 - How to change static parameters through SPFILE parameter file.
NOTE: PGA_AGGREGATE_TARGET influences the workarea sizes internally for sorts, hash joins, bitmap index operations, etc. This is a target. PGA memory will grow as it needs to on the database and will not be restricted by the PGA_AGGREGATE_TARGET settings.
At 11g, the PGA can be auto-tuned along with SGA memory to meet demand for spikes in user PGA memory when the OS is already pressured for memory.
At 11g, the view V$MEMORY_RESIZE_OPS will show memory tuning going on within the database between the SGA components and PGA.
- Increase the amount of memory a UNIX process can request and use from the operating system. This usually refers to stack and/or data size UNIX process resource limits.
This process varies slightly depending on the UNIX platform and the type of UNIX shell you are using. Generally speaking either the 'limit' or 'ulimit' command will allow your System Administrator to increase memory and data size limits. Oracle Support cannot recommend a specific value for these limits. However, doubling existing values or setting them to 'unlimited' is usually sufficient.
For more information please refer to Document 188149.1 - How to Display and Change UNIX Process Resource Limits
- Increase the amount of swap available on your system. You should have 2-3 times the amount of physical memory available as swap space. For more information, see Document 1016233.6 - How to Display the Amount of Physical Memory and Swap Space on UNIX Systems
- Finally, if you still experience the problem after addressing the above issues, it's recommended that you move to the latest patchset release to eliminate any possible Oracle product defects. For more information, see Document 169547.1 - Understanding and Obtaining Oracle RDBMS Patchsets [Video]
REFERENCES
NOTE:19836.1 - OERR: ORA 4030 "out of process memory when trying to allocate %s bytes (%s,%s)NOTE:174555.1 - UNIX: Determining the Size of an Oracle Process
NOTE:1023744.6 - ORA-04030 -07324: AFTER INCREASING THE SGA OR EXECUTING A LARGE QUERY
NOTE:61896.1 - SOLARIS: SGA size, sgabeg attach address and Sun architectures
NOTE:233869.1 - Diagnosing and Resolving ORA-4030 Errors
NOTE:399497.1 - FAQ: ORA-4030 [Video]
NOTE:153655.1 - SOLARIS: Determining Oracle Memory Usage on Solaris
NOTE:123754.1 - AIX: Determining Oracle Memory Usage On AIX
PLSQL Procedure 引起 ORA-04030: (pga heap,control file i/o buffer) 和 ORA-04030: (koh-kghu sessi,pmuccst: adt/record) 或 ORA-04030: (koh-kghucall ,pmucalm coll) 的错误 (文档 ID 1626254.1)
文档内容
| 症状 |
| 更改 |
| 原因 |
| 解决方案 |
| 参考 |
适用于:
Oracle Database - Enterprise Edition - 版本 11.2.0.1 和更高版本本文档所含信息适用于所有平台
症状
您运行了一个 PL/SQL package 或者 procedure，当进程使用了 4GB 的内存时总是会遇到 ORA-4030 异常。 _PGA_MAX_SIZE 和 PGA_AGGREGATE_TARGET 已经设置到一个大于 4GB 的值了，但是当 4GB 内存被使用时相同的错误仍然持续报出。
错误看起来类似于：
ORA-04030: out of process memory when trying to allocate 16328 bytes (koh-kghu sessi,pmuccst: adt/record)
- 或者 -
ORA-04030: out of process memory when trying to allocate 16328 bytes (koh-kghucall ,pmucalm coll)
ORA-06512: at line ...
更改
升级数据库到 11.2.0.1 或更高的版本.
原因
通过 trace 文件也能够确认进程被限制在 4GB 的大小。
TOP 10 MEMORY USES FOR THIS PROCESS
---------------------------------------
100% 4057 MB, 260558 chunks: "pmuccst: adt/record " PL/SQL
koh-kghu sessi ds=0x2aec85f2b810 dsprt=0x2aec85b66ac0
0% 1091 KB, 22 chunks: "free memory "
top call heap ds=0xa2c2a60 dsprt=(nil)
0% 546 KB, 102 chunks: "free memory "
callheap ds=0xa2c1c18 dsprt=0xa2c2a60
0% 425 KB, 39 chunks: "permanent memory " SQL
sort subheap ds=0x2aec861809c8 dsprt=0x2aec85f5f738
0% 263 KB, 3 chunks: "static frame of inst " PL/SQL
koh-kghu sessi ds=0x2aec85fd2088 dsprt=0x2aec85b66ac0
0% 191 KB, 21 chunks: "permanent memory "
pga heap ds=0xa2bd460 dsprt=(nil)
0% 137 KB, 3 chunks: "recursive addr reg file " PL/SQL
koh-kghu sessi ds=0x2aec85fd2088 dsprt=0x2aec85b66ac0
0% 83 KB, 8 chunks: "permanent memory " SQL
kxs-heap-w ds=0x2aec85fbf068 dsprt=0x2aec85b66ac0
0% 79 KB, 18 chunks: "permanent memory "
session heap ds=0x2aec85b66ac0 dsprt=0xa2c2c80
0% 62 KB, 32 chunks: "free memory "
session heap ds=0x2aec85b66ac0 dsprt=0xa2c2c80
=======================================
PRIVATE MEMORY SUMMARY FOR THIS PROCESS
---------------------------------------
******************************************************
PRIVATE HEAP SUMMARY DUMP
4074 MB total: <----- 在这我们看到了进程遇到了 4GB 的限制
4072 MB commented, 192 KB permanent
1131 KB free (768 KB in empty extents),
4071 MB, 1 heap: "session heap "
------------------------------------------------------
Summary of subheaps at depth 1
4070 MB total:
4069 MB commented, 95 KB permanent
639 KB free (569 KB in empty extents),
4068 MB, 20 heaps: "koh-kghu sessi " 4 KB free held
------------------------------------------------------
Summary of subheaps at depth 2
4059 MB total:
4058 MB commented, 150 KB permanent
100 KB free (56 KB in empty extents),
4057 MB, 260558 chunks: "pmuccst: adt/record "
=========================================
在 trace 文件中更深层的信息，我们看到 process map 遇到了 65536 行的限制
----- Process Map Dump -----
00400000-0954f000 r-xp 00000000 fd:09 3131376 /e00/oracle/prod/v11.2.0/bin/oracle <-Line 1
0974e000-0a2be000 rwxp 0914e000 fd:09 3131376 /e00/oracle/prod/v11.2.0/bin/oracle
0a2be000-0a304000 rwxp 0a2be000 00:00 0
0c8c9000-0c950000 rwxp 0c8c9000 00:00 0 [heap]
60000000-60001000 r-xs 00000000 00:13 9374560 /dev/shm/ora_DSSP_11698195_0
60001000-70000000 rwxs 00001000 00:13 9374560 /dev/shm/ora_DSSP_11698195_0
70000000-80000000 rwxs 00000000 00:13 9374561 /dev/shm/ora_DSSP_11698195_1
80000000-90000000 rwxs 00000000 00:13 9374565 /dev/shm/ora_DSSP_11730964_0
90000000-a0000000 rwxs 00000000 00:13 9374566 /dev/shm/ora_DSSP_11730964_1
a0000000-b0000000 rwxs 00000000 00:13 9374569 /dev/shm/ora_DSSP_11763733_0
b00
2aed84a4f000-2aed86e5f000 rwxp febe2000 00:11 29160 /dev/zero
7fffea3ca000-7fffea418000 rwxp 7ffffffb1000 00:00 0 [stack]
ffffffffff600000-ffffffffffe00000 ---p 00000000 00:00 0 [vdso] <---在 map dump 的结尾(Process Map Dump 的行号是 65537)
******************* End of process map dump ***********
从 OS 角度来看，这些错误的出现通常是因为 map 条目耗尽造成的。
每个进程仅仅有 65536 个 memory map 条目。
在 trace 中内存的分配或者错误可能包括（但不仅限于）：
- "pmucalm coll"
- "pmuccst: adt/re" or "pmuccst: adt/record"
- "pl/sql vc2"
- "permanent memory " SQL
- "kkqgAllocEle.n "
解决方案
在 OS 或者在数据库层面来改变上限：
- 在 OS 层面来改变页数：
more /proc/sys/vm/max_map_count
sysctl -w vm.max_map_count=200000 (例子)
- 在数据库的初始化参数文件中设置下面的参数，来调整 realfree heap pagesize。然后重启数据库。
_use_realfree_heap=TRUE
_realfree_heap_pagesize_hint = 262144
缺省 realfree allocator pagesize 是 64KB（65536），这样 64K 的条目能接纳 4GB 的内存。使用 256kB (262144)，限制将会增大到 16GB。
参考
NOTE:1315884.1 - ORA-04030 Error For Memory Allocation Type "pl/sql vc2"BUG:11852492 - ORA-4030 OCCURS WHEN PGA EXCEEDS 4GB.
ORA-04030 Error For Memory Allocation Type "pl/sql vc2" (文档 ID 1315884.1)
In this Document
| Goal |
| Solution |
APPLIES TO:
Oracle Database - Enterprise Edition - Version 8.1.7.0 and laterInformation in this document applies to any platform.
GOAL
Why is the following error raised:
Why doesn't PGA_AGGREGATE_TARGET limit the processes' memory in this case?
Why doesn't _PGA_MAX_SIZE help either?
SOLUTION
The memory allocation type "pl/sql vc2" is used when Oracle needs to allocate memory for a local variable in PL/SQL code. Some examples of PL/SQL local variables are as follows:
TYPE BigVArray IS VARRAY(10000) OF VARCHAR2(32000); -- VARRAY type
...
DECLARE
BigVar VARCHAR2(32000);
...
The problem can typically occur if:
- a procedure has 1 or more large VARRAYs defined, and is called many times,
- a procedure has 1 or more large local variables, and is called many times,
- or either of the above situations occur, but the procedure is (accidentally) called in an infinite loop.
The cause of the ORA-4030 error is usually a PL/SQL coding issue, as very larger amounts of data should really be stored in a table, or in the case of an infinite loop, the procedure call needs to have a limit.
The reason why neither PGA_AGGREGATE_TARGET nor _PGA_MAX_SIZE has any impact, is because PL/SQL local variables are not managed by the regular Oracle memory heaps. PL/SQL local variables are just like other programming languages' local variables and should adhere to good coding practices. Their size is only limited by the operating system memory limits.
About Me
...............................................................................................................................
● 本文整理自网络
● 本文在itpub（http://blog.itpub.net/26736162）、博客园（http://www.cnblogs.com/lhrbest）和个人微信公众号（xiaomaimiaolhr）上有同步更新
● 本文itpub地址：http://blog.itpub.net/26736162/abstract/1/
● 本文博客园地址：http://www.cnblogs.com/lhrbest
● 本文pdf版及小麦苗云盘地址：http://blog.itpub.net/26736162/viewspace-1624453/
● 数据库笔试面试题库及解答：http://blog.itpub.net/26736162/viewspace-2134706/
● QQ群：230161599 微信群：私聊
● 联系我请加QQ好友(646634621)，注明添加缘由
● 于 2017-04-28 09:00 ~ 2017-04-30 22:00 在魔都完成
● 文章内容来源于小麦苗的学习笔记，部分整理自网络，若有侵权或不当之处还请谅解
● 版权所有，欢迎分享本文，转载请保留出处
...............................................................................................................................
拿起手机使用微信客户端扫描下边的左边图片来关注小麦苗的微信公众号：xiaomaimiaolhr，扫描右边的二维码加入小麦苗的QQ群，学习最实用的数据库技术。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26736162/viewspace-2138387/，如需转载，请注明出处，否则将追究法律责任。