当试图在共享池中分配大块连续内存而失败时， Oracle 会首先从池中清理当前不用的对象从而使得空闲内存碎片(chunk:内存块)得以合并。如果这样仍然没有足够大的单个 chunk 来满足分配需要，则会产生 ORA-04031 报错。有许多 ORA-04031错误直接原因都是由于共享池的大小或调整不当造成的。
Note：报 ORA-4031 错误的进程并不总是内存消耗的元凶。错误的发生仅是因为此进程无法得到所需内存而造成的。
如果已经按所有步骤正确设置了共享池大小(SHARD_POOL_SIZE) , 但此问题仍然产生时，除了从应用（例如：使用绑定变量查询替代静态 SQL 等）入手进行分析解决问题外，也可从其他 trace 文件中获得共享池的一些快照信息==>
修改 init.ora 参数文件，增加以下事件以从追踪文件中获取相关问题信息：
event = "4031 trace name errorstack level 3"
event = "4031 trace name HEAPDUMP level 3"
注意： 除非重启实例， 否则这个参数文件设置不会起效。 从 Oracle 9.2.0.5 版本起，除了在请求 heapdump 时使用 level 1,2,3 或 32 你同样可以使用相同等级并加值536870912.这样将会在此等级上再进一步显示 5 个最大的 subheaps 同时每个subheap 下显示相关 5 个最大的 heap areas.
如果问题可以重现，则可在执行有问题的 SQL 语句前，在会话级别对事件进行设置：
SQL> alter session set events '4031 trace name errorstack level 3';
SQL> alter session set events '4031 trace name HEAPDUMP level 536870914';
Level 536870912 转储 5 个最大 subheaps 并且对应每个 subheap 将显示其 5 个最大heap areas。由于 ORA-04031 错误可能在不同池中发生(共享池，大池，java池，流池等)，其 level 值的设置可参照如下：
Note：如果 4031 错误出现频繁，在实例级设置此事件(heapdump 536870914)将会产生许多大的trace文件. 这不仅会影响数据库性能而且可能使数据库挂起 (某些情况下可能会使得数据库崩溃). 因此有必要及时使用以下语句关闭此事件踪：
alter system set events '4031 trace name HEAPDUMP off';
我们也通过 Library cache 转储来帮助确认产生 ora-4031 问题的游标:
请注意：在 Oracle 9.2.0.5+, 10g 和 11g 版本中，4031 trace 文件默认会在ORA-4031发生时产生并存放于 user_dump_dest 目录。如果你的数据库版本是其中的一个，那么你就不需要进行相关设置来生成 4031 trace 文件。
ORA-4031 诊断 —>
检查 Alert 日志并查看错误是否记录。注意不是所有 ORA-4031 错误都会记录在 alert 日志中。
如果错误被记录，请检查 SGA 的哪部分收到此错误。是共享池，大池，java池或 streams 池?
查询 v$sgastat 以检查是否有组件表现出非正常增长.
查询 v$librarycache 并检查:
- 有无无效对象 (多为 DDL 语句)
- 有无重载 (Library cache 可能不够大)
- 内存命中率 (低命中率可能是非共享游标造成的)
检查是否存在高 Version Counts 的游标。 可通过 v$sql_shared_cursor 查询.如果存在某父游标下有许多子游标的情况， 检查不可共享的原因. 大量子游标会加快共享池的碎片化. 请确认应用正在使用绑定变量方式查询.
我们的优势：
Microsoft中国核心经销商
Oracle的OPN及ESL
VMWARE企业级代理商
Symantec 企业级合作伙伴
REDHAT企业级合作伙伴
易迅通金牌合作伙伴
