适用于：

目标：

订单管理套件在ＯＭ库ORA-4030 ORA-4031的错误。

ORA-4030/4031的故障排除方法。
简介：

本文档旨在帮助OM公司的工程师和客户明白为什么ORA-4030，ORA-4031错误会发生，以及如何去解决这些问题。
许多SR的记录在OM过程时遇到这个错误。要经过一个非常复杂的过程才能处理这个问题。本文档中的信息关于这个问题上的几个漏洞和建议。

问题和答案：

１．了解ORA-4030/4031错误

ORA-4030和ORA-4031错误发生时，操作系统（OS）不能分配足够的内存块，以支持一个正在运行的进程的内存消耗。简要了解Oracle的内存架构，将揭示一些关于这个问题的办法。

Oracle使用的内存来存储会话连接到数据的底层上，本次回话产生进程的相关信息有正在执行的程序代码，使用过程中的缓存数据等。Oracle使用的内存的基本结构是：

一）  系统全局区（SGA）组成的数据库缓冲区高速缓存，重做日志缓冲区，共享池，大池。这个区域是一个数据库实例的所有用户共享。 SGA内存被分配在实例中启动。 SGA的大小是由一些数据库（INIT.ORA）参数，如：SHARED_POOL_SIZE，DB_BLOCK_SIZE决定DB_BLOCK_BUFFERS，LOG_BUFFER的。

二）  程序全局区（PGA），栈和数据区组成。这个区域被分配到一个特定的过程中，当用户连接到数据库并启动会话。这方面的专门用于这一进程不共享。 PGA的大小取决于连接时，是由多种因素控制（稍后讨论）。 PGA_AGGREGATE_TARGET的数据库参数确定多少总内存可分配的一个实例中运行的所有进程。

三）  软件代码区是用来存放正在执行的代码的内存部分。当一个Oracle进程从操作系统请求更多的内存，但操作系统无法找到足够的可用内存从PGA分配的ORA-4030错误造成。可能发生如果操作系统没有足够的物理内存或交换空间的过程中提供，或操作系统配置，以限制可用的内存量的过程，或已经遇到一个Oracle错误。ORA-4031错误发生时，有枯竭的SGA区，OS是无法从共享区分配内存。应当指出，将通过这台机器上运行的实例共享一台机器的总RAM。例如，运行2个实例将有2 SGA的分配，余下的将在PGA中的每个实例正在运行的进程之间共享内存。还要注意的是SGA的大小影响PGA的留下的空间量。有时候，我们看到了发展建议减少SGA允许更多的内存分配给PGA（但可以有其他的影响）。

看到以下的项目6.B可能是这个样子的：ORA-4030错误在FDPSTP ORACLE错误4030

原因：FDPSTP失败，由于ORA-04030：进程内存不足时尝试分配16396字节（KOH-kghu呼叫的，PL / SQL VC2）...

括号中的数据告诉我们，记忆体元件失败。在这个例子中，“KOH-kghu呼叫堆和subheap的pmuccst”的通常用于PL / SQL集合和数组一样，索引表等堆转储分析提供了更多细节上的错误（见下面的项目3.E） 。

ORA-4031错误，可能是这个样子

ksedmp：内部或致命错误

ORA-04031：无法分配76488字节的共享内存（“共享池”，“QP_PREQ_GRP”，“PL / SQL的MPCODE”，“BAMIMA：巴姆缓冲区”）

ORA-06508：PL / SQL中：无法找到程序单元被称为本次会议的当前SQL语句：OE_ORDER_IMPORT_MAIN_PVT.ORDER_IMPORT_CONC_PGM（：errbufRC的：A0，内容：A1，A2，A3，A4纸，A5）的结束;...

2．为什么ORA-4030/4031错误会发生

OM套件使用PL / SQL集合的进程中来存储数据。例如，定价发动机采用像qp_preq_lines_tmp表保存在内存中的数据处理定价请求。在处理销售订单，订单的行读入内存如下：

这里的订单的所有行读入的“x_line_tbl'，这是一个集合的索引表类型存储在PGA内存。多行上的顺序，然后利用更多的内存。

问题发生时，这些藏品长得过大，超过操作系统的物理内存容量。通常情况下，我们看到资源密集的进程正在运行时，如订舱，调度，定价，或进口（可调用其他进程之一）当OM的错误。有时候代码错误可能会导致错误，像游标管理不善，太多的人可能打开游标等。

在其他时间可能会出现错误时，操作系统尝试加载到内存中执行一个PL / SQL块或包。例如，有时可能会出现问题时调用了定价引擎，然后执行生成属性映射程序。伴随着次要的错误，例如，我们可能会看到ORA-4030/4031错误：ORA-6508：无法找到程序单元被称为（参见Bug 5357819）。

3．应收集哪些数据

最初，这样的错误应该由服务器技术（ATG）组进行调查，以确保客户的环境是否正确配置为运行Oracle应用程序。他们都有更好的装备审查的内存大小和分配，并告知，如果正遇到任何已知的错误（如内存泄漏）。一旦他们有一定的问题不在于通过调整操作系统参数进行解析，然后在SR应看着由产品工程师（有机质，QP，WSH的，RLM的，锆石等）。如果SR进入该产品的队列中，然后我们应该收集尽可能错误的数据，以帮助ATG组更好地了解失败的过程。在OM，我们需要确定哪个进程失败，什么样的数据量导致系统要强调的。例如，如果进口秩序的过程中错误被命中，那么有多少条记录进行处理之前发生错误：10000或15000或50000等，如果预订失败如在订单上的行数的信息，或是否套正在使用或项目类型（ATO，动力输出等）是非常有用的。

这将有助于我们确定正在打什么样的内存限制，那么我们可以提供一些建议避免错误。

有价值诊断：

一）  获取init.ora文件（或运行bde_chkcbo.sq），以验证数据库参数。 @参数值的详细信息，请参阅未公开说明216205.1（内部说明）。像一个数据库跟踪和调试文件通常诊断将有助于查明当时正在执行的应用程序代码，并可以表明错误使用游标循环等。

二）  检查PGA_AGGREGATE_TARGET（在32位操作系统，这可高达4GB，64位操作系统，它可以是> 4GB）。该参数决定了在一个实例中运行的所有进程（PGA），可分配的内存量。可以使用下面的SQL：SQL> SELECT * GV $ PGASTAT;

三）  你可以看到使用的进程内存（PGA），使用以下查询：只要你启动该程序，找出会话ID的数据库会议（使用oracle_session_id，的fnd_concurrent_requests oracle_process_id列）的表。

SQL> COL名称格式A30的SQL>选择SID，名称，价值从V $ STATNAME N，V $ SESSTAT小号其中sid = - 代替你浓程序会话的SID和n.STATISTIC＃= s.STATISTIC＃名称如“会话PGA％％％的内存订购3递增;---看到所有会话的PGA的使用SQL> SELECT名称，金额（价值），MAX（价值）从V $ SESSTAT S，V $ STATNAME列印s.statistic＃= n.statistic＃及（n.name LIKE'％PGA像'％UGA％'％'或n.name）组由n.name;---看到个别为每个会话的PGA使用的SQL>选择SID，名称，价值从V $ SESSTAT S，V $ STATNAME列印s.statistic＃= n.statistic＃及（n.name LIKE'％PGA像'％UGA％'％'或n.name）订购SID;

一）  你可以看到分配的共享内存（SGA），如下：

共享SQL>显示参数;

NAME TYPE值

--------------------------------------------------

_shared_pool_reserved_min_alloc大整数4100

hi_shared_memory_address整数0

max_shared_servers整数20

shared_memory_address整数0

SHARED_POOL_RESERVED_SIZE大整数30000000

shared_pool_size的大整数150994944

shared_server_sessions整数0

SHARED_SERVERS整数0

或如下：

二）  一个堆转储是有用的，在发生故障时的各种栈内存分配的快照。这可以得到如下（从错误5332178）

在SQL * Plus：获取堆转储级别事件“4030跟踪名称堆转储级别536870912 536870912使用”。SQL> ALTER SESSION事件'4030跟踪名称HEAPDUMP 536870912“;然后运行一个SQL脚本（例如wfretry.sql）重现错误。

输出看起来像这样：

如果长期运行的过程中，可以使用此方法。否则，如果进程结束太快，你可以尝试以前的方法（的SQL *加以上）。

三）  您还可以监视进程大小，在操作系统级别使用的命令一样：

PMAP，PS，顶部，自由，vmstat的运行PMAP-XS（spid是预订会议相应的数据库服务器进程的PID）运行在一个循环中的SAR-W，所以我们可以得到之前的4030错误值。

运行以下操作系统命令来获得物理和交换内存大小：

运行前的p命令看到的内存分配。

四）  在ORA-6508错误的情况下，下面的查询可以帮助找出失败的包和可能驻留在内存中：

SQL> SELECT名称，型，线，文本从all_errors像“OE_％，其中name'和雇主=“应用程序”;下面的查询将给予固定的对象的信息：

SQL> SELECT名称，类型，命名空间，SHARABLE_MEM，负载处决，锁，销，保持从

V ＄ db_object_cache其中name ='OE_DELAYED_REQUESTS_PVT“;

可以用下面的方法获得的ORA-6508错误的堆栈跟踪。

SQL> ALTER SYSTEM设定事件'6508跟踪名称ERRORSTACK“;

这将使6508错误的堆栈跟踪。现在尝试再次运行导入程序。

在为这个错误USER_DUMP_DEST，它会创建一个跟踪文件。然后禁用事件之后执行以下。

SQL> ALTER SYSTEM '6508跟踪关“的名称上下文中设置事件;

4．避免错误的一些最佳做法

请注意，这个错误，是一个在操作系统的内存水平，而不是数据库的问题。通常情况下，调整SQL或应用性能的补丁将无法避免这种类型的错误，虽然症状可能是一个性能问题，因为正在处理的数据量的相似。某些数据库参数（init.ora中）不影响内存是如何分配给进程。

问题通常可以通过调整某些内存分配和参数被规避，但是这并非总是如此。有一个进程可用的内存量的物理限制，因此，我们只能做这么多。在OM，这相当于以较少的数据放置在PL / SQL的集合结构，这意味着试图处理每笔交易的数据量小。

我们应该问的顾客，以较少的数据在可能的情况下运行的进程。例如，如果在订单管理的质量变化，对数百行尝试做一次100线。如果使用较少的数据是不是一种选择，然后再尝试的过程中，以限制资源争。例如，试运行进口秩序，没有预订的订单;或关闭自动调度和推迟到后台调度;或预填充尽可能接口表中的数据，以减少由违约发动机做的工作。定价中，我们可以尝试限制由发动机前完成的工作量填充的命令行上的价格表，或确保没有盲目的修饰语或灭活未使用的价目表，修饰符，定价阶段等（见调整定价引擎白皮书）。

如果问题是由于加载在内存中的一个包中的ORA-6508错误的情况下，失败，那么我们可能会建议顾客尝试寄托在内存中的包。这样一来，包将在需要时可用来执行。

若要固定在内存中封装，可以使用以下命令：

5．SR的样本错误

一）订购进口：6027765，5837874和5246616，提供可能的解决方法。

二）预订：5533728，5332178，5061182，4940965

三）质量的变化：5077005（奥姆补丁修复）

四）预订：6156030

五）其他：

2901354 - 设置WORKAREA_SIZE_POLICY为AUTO

3445124 - 执行的PL / SQL时遇到ORA-4030错误

6．其他注意事项

一）ulimit的作用下，（参见错误4940965）Oracle的内存分配是通过的ulimit限制。通过ulimit必须说“无限”数据段，这意味着内存可以长大的maxdsiz_64值。

尝试设置以下内容，看看问题是否是重复的。

1．设置maxdsiz_64到4GB

2．设置_pga_max_size到4GB

3．确保的ulimit显示，至少在数据段无限。

使用以下命令来验证ulimit设置：

如果程序需要超过4GB上述可能仍然不能解决问题。

二）如何了解SGA的大小影响（参见Bug 5332178）

在32位Linux的一个进程拥有4GB内存的地址空间。与标准内核1GB用于内核地址，只有3GB可以使用的过程。使用hugemem内核，可以使用4GB的进程。

这包括执行代码，栈，共享库，共享内存和私人进程内存（PGA）。

如果我们用大SGA（共享内存）和增加mapped_base的地址，我们可用的进程的内存在同一时间减少。如果顾客真正需要的3.4gb SGA和进程在同一时间需要大量的私有内存，顾客使用64位的HW / SW或使用VLM的选项。一个单一的过程，不能处理超过4GB的内存。一个单一的过程中使用了2.3 GB，最大PGA SGA一些100MB是有限的。 PGA_AGGREGATE_TARGET的限制PGA连接到同一个数据库中的所有进程的内存量。 PGA_AGGREGATE_TARGET的= 4096b，我们可以大约80个并发客户端分配50MB的PGA的管理。我们会收到A-4030，如果乘以进程的PGA大小的进程数达到PGA_AGGREGATE_TARGET的。但这改变的最大PGA我们每个进程分配的32位架构的结果。

有了一个2.3MB的SGA，有700MB留下的一切，包括PGA，堆栈，代码共享库等如果ORA-4030据报道，因为我们打了一个32位进程的地址限制，不会增加pga_aggregate_target的帮助。如果我们转移SGA基地址和减少SGA的2GB或更少，我们将增加可用的PGA。

使用VLM共享内存映射到内存的文件系统。共享池的访问是通过内存窗口，默认情况下，500MB大小的窗口。如果顾客使用VLM的选项，部分共享内存映射到共享内存文件系统。这可能允许较低的mapped_base的，从而有更多的PGA内存空间。

注260152.1和200266.1注中可以找到详细信息。

如果客户需要为PGA分配更多的内存资源，他们应该减少SGA的大小保持在传统的共享池。降低mapped_base的将减少每个进程的PGA大小。另外，检查，如果可能回到默认mapped_base的设置，。尝试使用hugemem内核，而不是SMP内核，这使得每一道工序，以解决更多的内存。

三）有益的文章：

note.1028623.6 SOLARIS系统：如何迁移的SGA（32位）

note.396940.1故障排除和诊断ORA-4031错误

note.233869.1诊断和解决ORA-4030错误

总结

在文件中提出的信息将帮助我们收集正确的数据调查ORA-4030/4031类型错误。这些数据应收集由OM工程师之前记录错误或通过SR至90mg/kg，以确保该问题上取得进展。

同时，顾客的期望，应正确设置。大部分时间都没有解决这些错误代码修复。发展不能再建筑师申请变更利用集合的模式，在大多数情况下，这些实际帮助的应用程序的性能。通常，它需要一些数据库和操作系统参数的调整，找到合适的内存分配的过程中完成。但它经常需要小批量的数据运行时，一切都失败了。

错误

ORA-4031，ORA-6508，ORA-4030，ORA-6510错误6508，4031错误，错误4030; 6508 ERROR 4030错误