首页 > 开发 > 综合 > 正文

分析和解决ora-4030错误

2024-07-21 02:40:31
字体:
来源:转载
供稿:网友

  
分析和解决ora-4030错误



ORA-4030意味着什么?



    这个错误意味着Oracle服务器进程不能从操作系统获得更多的内存。这里的内存指的是PGA(程序全局区)以及由配置决定的它的子项。对于专用的服务器进程,内存包括堆栈区、UGA(用户全局区)。UGA包括用户会话数据、游标信息和排序区。在多线程配置中(共享服务器),UGA处于SGA(系统全局区)中,它不会造成ora-4030错误。



    因此,ora-4030意味着进程需要更多的内存(堆栈、UGA或者PGA)来执行它的工作。



是什么引起了这个错误?



这个错误表示操作系统不能分配足够的内存。这个错误可能是你的进程本身引起的,例如你的进程需要太多的内存,或者其它的原因引起操作系统内存枯竭,例如SGA区分得太大或者太多的进程竞争系统虚拟内存(物理内存+交换分区)。许多操作系统会限制某个进程获得的内存以保证系统稳定。



请按以下步骤检查你的系统:



·       是否仍有足够的内存供分配?



·       操作系统是否有限制?



·       Oracle数据库是否有限制?



·       哪一个进程需要过多的内存?



·       如何收集那个(需要过多内存的)进程正在做什么的信息?



这些将在下一节里讨论。



进一步讨论主题:



·       避免此类错误的一般建议



·       参考



是否仍有足够的内存供分配?



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



1.OpenVMS系统:显示那些能告诉你物理内存和页面文件使用情况的信息。



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  2261    60201088  249984  DISK$BOBBIE_USER3:[SYS0.PAGEFILE]PAGEFILE.SYS 462224  405296  499968



    作为一般的原则,页面文件中的空闲容量总量应该不低于总容量的一半。交换文件应该几乎不使用,空闲的容量应该几乎和总容量一样。




1.Windows系统:在任务治理器中查看内存使用情况。



2.Unix系统:每一个Unix系统都有自己的工具来检测全部内存的使用情况,例如top,vmstat…..,并且每一个系统都有所不同。



o        top常用来显示物理内存和交换空间的情况。



o        swapon –s 显示交换空间使用情况



o        vmstat 显示空闲物理内存情况



Sample top output on linux:



在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 quotas)和页面文件配额(pagefile quota)。请查询OpenVMS使用指南确定配额情况和如何修改它们。根据使用进程的不同以及启动它们方式的不同,配额使用将不同于oracle的统计。PRocess/id=<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:   LOGINFlags:



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: 0



2.Windows系统:在微软的windows操作系统上,oracle进程集作为一个进程的许多线程来运行。
地址空间不能超过2GB(包括堆栈、PGA、SGA)。这个限制可以突破到3GB或更高。(请看oracle文档<NOTE:46001.1>)。关于oracle数据库和Windows NT内存结构的情况,请查询技术公告板。Oracle进程使用的总的内存情况(不包括进程堆栈和代码)可以用query查看。



3.Unix系统:使用内置的shell命令: limit/ulimit。注重那些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



有可能是内存限制定得太小了,需要增大它。也可能是我们需索得太多



Oracle数据库是否有限制?



    从oracle 9i以后,有一个参数决定一个oracle实例可以分配到PGA总量。<Note:223730.1>"Automatic PGA Memory Managment in 9i"提供了更多关于这方面的信息。下面的查询可以用来找出分配给所有会话的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数据库PGA和UGA的运行情况。



SQL>col name format a30SQL>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数据库的服务器进程使用了过多的内存。一般地,对于服务器进程来说,oracle数据库和操作系统之间或多或少的可以就内存的使用达成一致。下面的命令答应你从操作系统的角度找出进程的内存使用量。



1.OpenVMS系统:“show system”命令给出进程和资源的使用情况的概览。那些频繁调用页面失败的进程经常消耗了大量的虚拟内存。“page”列指出物理内存的使用情况。“show process/continious”(原文如此,我怀疑是continuous)命令则给出物理内存(工作页面区)和虚拟内存的使用情况。



$ show system/page



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系统:对于微软的windows操作系统来说,oracle进程集作为一个进程的许多线程来运行。
到目前为止,我还没有找到一个方法来查看某个线程的内存使用情况。然而我们可以检查出oracle是否对操作系统分配的内存感到满足。从操作系统的角度来看,我们可以使用任务治理器。调出任务治理器,点击“查看”按钮,选择“选择列”,在弹出的窗口中在“虚拟内存大小”前打上勾。oracle.exe进程使用的虚拟内存大小( VM size)应该和SGA、PGA和进程堆栈以及代码使用的内存总量相匹配。下面的查询命令可以给出oracle使用的内存量,然而,这不包括进程堆栈以及代码使用的内存量。



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



在我的系统上,任务治理器中显示的虚拟内存大小比上面的查询出的内存使用量多大约30MB。当你确认是oracle使用了这个内存,这个查询将给出哪一个会话用得最多。



3.Unix系统:“top”工具是一个很有用的工具,你能够定制显示和排序的列。“ps”命令在大多数系统中可以使用,但也有些不能。例如,在Linux上,“ps -AF --sort resident”将列出所有的进程最近的最大常驻内存集(resident set)(注二)。你也可参考<Note:174555.1> "UNIX: Determining the Size of an Oracle Process". 



如何收集那个(需要过多内存的)进程正在做什么的信息?



    本节将只讨论oracle服务器进程。使用前面几节介绍的方法,你应该可以判定一个或多个oracle服务器进程造成了内存资源的枯竭。记住并不总是由于进程造成了内存资源的枯竭从而导致ORA-4030错误。这个错误仅仅意味着进程不能获得它需要的内存资源。



    假如进程不断增长对内存的需求,我们可以在它运行的时候查看一下它的情况。



o  你可以用下面的查询语句在v$sql_area表中查询有什么进程正在执行中。



SQL> select sql_text  from v$sql_area a, v$session s



where a.address = s.sql_address and s.sid = <SID>;



o  We can force a heapdump and have it examined by oracle support services。(这句不知如何译)



SQL> oradebug unlimitSQL> oradebug setorapid 10 (这是对应 oracle pid, 用“setospid”对应操作系统的进程id)SQL> oradebug dump heapdump 7



    假如问题不再发生,或者某些进程太快而不能作这样的检查,很有可能这就是引起内存枯竭的原因。我们可以在这个进程引起这个错误时使用事件集来获得一个 heapdump.



SQL> alter session set events '4030 trace name heapdump level 25';



或者在数据库的init.ora文件中设置这个事件。<Note:21234.1> EVENT: 10261 "Limit the size of the PGA heap"    这个dump能帮助Oracle Support分析并找出引起过多的内存分配的原因。



对于如何避免这个错误的一般建议。



o  正如前面提到的一样,某些操作会需要大量的内存。对于排序操作来说,减少SORT_AREA_SIZE可能有所帮助。Oracle服务器进程会在PGA中分配排序操作需要的SORT_AREA_SIZE字节。假如完成某个查询需要过多的内存,服务器进程将会使用临时段。这意味着,当查询需要大量的排序操作时,更少的SORT_AREA_SIZE可以使得执行更紧凑。



o  对于9i或更高版本的oracle数据库,可以设备参数WORKAREA_SIZE_POLICY为AUTO来打开自动SQL execution内存治理功能,也可以在初始化文件中指定PGA_AGGREGATE_TARGET的大小。



  <Note:262946.1> "Performance Issues After Increasing Workload",   <Note:223730.1> "Automatic PGA Memory Managment in 9i",   <Note:223299.1> "Top Oracle 9i init.ora Parameters Affecting Performance" 



o  PL/SQL例程也可能会需要大量内存,因此有必要在你的应用程序中重写这部分查询代码。假如某个PL/SQL表经常被使用,它确实会在PGA中分配一块内存。



o  再看一下优化策略,由于排序操作可能某些访问路径会需要太多的内存,函数调用返回过多的行等等……



o  在某些操作系统上,例如Microsoft windows,SGA的大小应该降低,以便于PGA获得更大的内存。




o  确信你的操作系统和oracle数据库的内存限制是适度的。



o  确信有足够的内存(物理内存和交换空间)。



参考



General:



<Note:237899.1> Resolving ORA-4030 Errors After Upgrading



NT:



<Note:116076.1> Tackling ORA-4030 on WindowsNT



<Note:46001.1>  Oracle Database and the Windows NT memory architecture, Technical Bulletin



Unix:



<Note:199746.1> How to Resolve ORA-4030 Errors on UNIX (unix specific but general enough for some suggestions)



UNIX: Determining the Size of an Oracle Process




 


VMS:



<Note:67033.1> Background process quotas <Note:68663.1> Dedicated server process quotas (SQL*Net V2.3.3, V8.0.X)<Note:70671.1> Process quotas for Bequeath connections (V7, V8)<Note:68849.1> Bequeath listener process quotas (V7, V8)<Note:68226.1> Listener process quotas (SQL*Net V2.3.3, V8.0.X)




 


@ Internal:



@ <Note:21234.1> EVENT: 10261 "Limit the size of the PGA heap"



@ This event is very usefull. It will cause the process to dump information when the PGA grows above the specified limit




 


本人注一:工作(页面)区(working set):1.为避免过多的调页所必须激活的用户页面的集合。2.为避免系统失效,调页所需要的实存容量。



本人注二:常驻内存集(resident set):在虚存系统中,任一时候都存在于主存储器内的某个程序的页面 或程序段的全部。




 

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表