适用于:

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)组成。其内容取决于server配置。

对于专用的server进程,内存包括堆栈以及用于保存用户会话数据、游标信息和排序区的 UGA(User Global Area)。

在多线程配置中(共享server)。UGA 被分配在 SGA(System Global Area)中,所以在这样的配置下 UGA 不是造成 ORA-4030 错误的原因。



因此。ORA-4030 表示进程须要很多其它内存(堆栈 UGA 或 PGA)来运行其任务。

是什么导致了该错误?

因为发生了这个错误,您因此无法从操作系统分配内存。

这个错误可能是进程本身导致的,比如进程须要过多的内存。或者一些其它原因导致操作系统内存被耗尽。比如 SGA 太大或系统虚拟内存(物理内存 + 交换空间)中要容纳的进程过多。很多操作系统会对单个进程可以获取的内存量加以限制。以便自我保护。所以我们就会有下列问题:

问题:

以下我们将讨论这些内容。

其它主题:

是否仍然有足够的可用内存?

要回答这个问题,我们须要使用操作系统特定的工具来检查内存使用情况。

  1. 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



    作为一般准则。页面文件里的可用空间总和应不低于整个空间总和的一半。

    交换文件应差点儿不使用,可用空间的大小应大致等于总空间的大小。

  2. Windows 系统:在“任务管理器”的性能选项卡中检查内存使用情况。

  3. 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

                                                     .....

假设有足够的内存可用,请检查操作系统是否存在强制限制。

假设内存已被耗尽,我们就须要找出内存被用到了哪些地方。

是否设置了操作系统限制?

假设似乎仍剩余大量的虚拟内存。那么有可能是我们须要使用的内存量是不被同意的。以下的步骤能够用来检查由操作系统实施的限制。

  1. 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:

  2. Windows 系统:在 Microsoft Windows 操作系统中,Oracle 各个进程是在一个进程中以多线程实施的。

    对于 32 位的系统。可寻址的内存量为 2Gb(包含堆栈、PGA 和 SGA)。此限制能够添加到 3Gb 或更高。有关很多其它信息,请參阅“Oracle Database and the Windows NT memory architecture, Technical Bulletin”。

    对于 64 位的系统这个限制就高多了。Oracle 进程使用的总内存(不包含进程堆栈和代码)可通过此

    _afrLoop=530779337408552&id=1548826.1&_afrWindowMode=0&_adf.ctrl-state=9qj3whj3w_77#query_total_memory">查询进行确定。

  3. 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 进程。

通常,对于server进程而言。Oracle 和操作系统之间基本都能够就内存的使用情况达成一致。通过下面命令,您能够查找操作系统中进程的内存使用情况。

  1. 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

  2. Windows 系统:在 Microsoft windows 系统中, Oracle 是通过在单个进程中使用多个线程来实施的。直到如今,尚未找到能够查看每一个线程的内存使用情况的方法。可是,我们能够检查 Oracle 和操作系统是否就 Oracle 所使用的内存达成一致。从操作系统的角度看,我们能够使用任务管理器。单击查看button并选择选择列(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 就是那个正在大量使用内存的进程时。查询会显示使用内存最多的会话

  3. Unix 系统:top 是一个很实用的工具,您能够自己定义列显示和基于keyword排序。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 =<SID>;

我们能够做heapdump,并将结果提交给 Oracle 技术支持:

SQL> select PID from v$process p, v$session s where p.addr=s.paddr and sid=<SID>;

SQL> oradebug setorapid <PID>

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技术支持project师可使用该heapdump查找过多内存分配的原因。

有关避免此错误的一般建议

  1. 如上所述。一些操作须要大量的内存。对于排序问题。降低 SORT_AREA_SIZE 会有所帮助。Oracle Server 进程会将 PGA 中的 SORT_AREA_SIZE 字节分配给排序操作。

    假设完毕搜索须要很多其它内存,server进程将会使用temporary segment。这意味着,降低 SORT_AREA_SIZE 会对须要大量排序操作的查询性能产生影响。

  2. 对于 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"

  3. PL/SQL 程序也可分配大量内存,因此可能须要重写应用程序的某些部分。

    虽然 PL/SQL 表很easy使用,但它确实须要在 PGA 中分配内存。

  4. 查看 optimizer 策略,一些訪问路径可能会因排序操作、较多行上的函数使用等原因而须要很多其它内存。

  5. 在某些操作系统上(比如 Microsoft Windows),可能要减少 SGA 的大小以便于 PGA 获得更大的内存。

  6. 确保您的操作系统和 Oracle 限制设置合理。

  7. 确保有足够的可用内存(物理内存和交换空间)。

參考

parent=DOCUMENT&sourceId=1548826.1&id=199746.1" style="font-family:Tahoma,Verdana,Helvetica,sans-serif; font-size:12px">NOTE:199746.1 -
How to Resolve ORA-4030 Errors on UNIX

parent=DOCUMENT&sourceId=1548826.1&id=46001.1" style="font-family:Tahoma,Verdana,Helvetica,sans-serif; font-size:12px">NOTE: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

parent=DOCUMENT&sourceId=1548826.1&id=1088267.1" style="font-family:Tahoma,Verdana,Helvetica,sans-serif; font-size:12px">NOTE:1088267.1 -
Master Note for Diagnosing OS Memory Problems and ORA-4030

诊断并解决 ORA-4030 错误 (Doc ID 1548826.1)的更多相关文章

  1. ORA-4031 错误故障排除与诊断[视频] (Doc ID 2016002.1)

    Copyright (c) 2019, Oracle. All rights reserved. Oracle Confidential.     ORA-4031 错误故障排除与诊断[视频] (Do ...

  2. Data Pump Export 数据泵导出因ORA-31693 ORA-02354 和 ORA-01555 错误且没有LOB损坏而失败 (Doc ID 1507116.1)

    Data Pump Export Fails With ORA-31693 ORA-02354 and ORA-01555 Errors And No LOB Corruption (Doc ID 1 ...

  3. Automatic Tuning of Undo Retention 常见问题 (Doc ID 1579779.1)

    Automatic Tuning of Undo Retention Common Issues (Doc ID 1579779.1) APPLIES TO: Oracle Database - En ...

  4. Master Note: Troubleshooting ORA-1548 error (Doc ID 1577988.1)

    APPLIES TO: Oracle Database Cloud Schema Service - Version N/A and laterOracle Database Exadata Clou ...

  5. ORA-20011 ORA-29913 and ORA-29400 with Associated KUP-XXXXX Errors from DBMS_STATS.GATHER_STATS_JOB(Doc ID 1274653.1)

    首先在alert log裡面頻繁的看見如下錯誤: DBMS_STATS: GATHER_STATS_JOB encountered errors.  Check the trace file. Err ...

  6. 转://诊断 Grid Infrastructure 启动问题 (文档 ID 1623340.1) .

    文档内容   用途   适用范围   详细信息   启动顺序:   集群状态   问题 1: OHASD 无法启动   问题 2: OHASD Agents  未启动   问题 3: OCSSD.BI ...

  7. 转 如何诊断和解决high version count 10.2.0.4 and 11.2.0.4

    转自 http://blog.csdn.net/notbaron/article/details/50927492 在Oracle 10g以上的版本,High version count可谓是一个臭名 ...

  8. 诊断 Grid Infrastructure 启动问题 (文档 ID 1623340.1)

    适用于: Oracle Database - Enterprise Edition - 版本 11.2.0.1 和更高版本本文档所含信息适用于所有平台 用途 本文提供了诊断 11GR2 和 12C G ...

  9. 11.2 Data Guard Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 1304939.1)

    11.2 Data Guard Physical Standby Switchover Best Practices using SQL*Plus (Doc ID 1304939.1) APPLIES ...

随机推荐

  1. Selenium启动项参数设置

    再Selenium中使用不同的Webdriver可能会有不一样的方法,有些相同的操作会得到不同的结果, 本文主要介绍的是Chrome()的使用方法. 其他的Webdriver可以参考官方文档 Chro ...

  2. Web Best Practices

    Web Best Practices General Google WebFundamentals - Github JavaScript Style Guide - Github Google In ...

  3. 【03】const

    [03]const 魔芋总结: 1,声明的是常量,一经声明,不得修改.必须声明的同时并赋值.否则报错. 2,只在声明所在的块级作用域内有效. 3,const命令声明的常量也是不提升,同样存在暂时性死区 ...

  4. [!] The ‘Pods-项目名XXX' target has frameworks with conflicting names:XXX.framework.

    在集成网易 即时通讯IM时报如下错误: [!] The ‘Pods-Yepu' target has frameworks with conflicting names: nimsdk.framewo ...

  5. hiho week 143

    P1 : hiho密码 Time Limit:10000ms Case Time Limit:1000ms Memory Limit:256MB Description 小Ho根据最近在密码学课上学习 ...

  6. zoj 2679 Old Bill

    Old Bill Time Limit: 2 Seconds      Memory Limit: 65536 KB Among grandfather��s papers a bill was fo ...

  7. 注册苹果开发者账号和iOS9打包上线

    链接: http://www.jianshu.com/p/507ca4e5fde0 http://blog.csdn.net/a283127993/article/details/45828175 i ...

  8. javaScriptCore 实战与小结

      源码在这,看不懂的直接撸源码就行,转载声明出处 原生调用JS的大致流程,做了个思维简图 这是代码流程 // JS数据 func getJSVar() { let context: JSContex ...

  9. 单点登录跳转失败(原因是 主票据申请子票据失败) asp.net 同站点下不同应用间不同版本Framework问题

    单点登录跳转失败(原因是 主票据申请子票据失败) asp.net 同站点下不同应用间不同版本Framework问题 今天遇到一个问题,在主站点现在配置的应用和主站点登录会话状态不能共享,进入子站点应用 ...

  10. 无记录时显示gridview表头,并增加一行显示“没有记录”【绑定SqlDataSource控件时】

    原文发布时间为:2008-08-04 -- 来源于本人的百度文章 [由搬家工具导入] using System;using System.Data;using System.Configuration ...