ORA-04030: out of process memory when trying to allocate 381096 bytes (kkoutlCreatePh,logde…

一、问题背景

2015年1月20日下午4点左右, eupdb数据库异常的缓慢,登陆到主机上执行命令都非常慢。通过vmstat发现系统计算内存使用非常多,page in/page out交换非常的严重。而在1月15日晚上也同时出现过类似的问题。通过分析当时的trace发现下列信息:

ORA-04030: out of process memory when trying to allocate 824504 bytes (pga heap,kco buffer)
ORA-04030: out of process memory when trying to allocate 381096 bytes (kkoutlCreatePh,logdef* : kkoabr)

此处可以发现系统无法分配多余的内存给应用进程。继续看Trace文件发现下列信息:

=======================================
TOP 10 MEMORY USES FOR THIS PROCESS
---------------------------------------
*** 2015-01-15 22:52:01.018
96%   15 GB, 56108 chunks: "permanent memory          "  SQL
         kkoutlCreatePh  ds=114165290  dsprt=1109b5b10                   <<<<< -- shows kkoutlCreatePh
 3%  495 MB, 42766 chunks: "free memory               "  
         top call heap   ds=110101460  dsprt=0
 0%   17 MB, 1660 chunks: "permanent memory          "  SQL
         kxs-heap-c      ds=1109b5b10  dsprt=110101460
 0%   11 MB, 96373 chunks: "optdef: qcopCreateOptInte "  
         TCHK^7e632a00   ds=1109d9580  dsprt=110d4c810
 0% 7904 KB, 3068 chunks: "free memory               "  SQL
         kkoutlCreatePh  ds=114165290  dsprt=1109b5b10
 0% 7226 KB, 48665 chunks: "opndef: qcopCreateOpnViaM "  
         TCHK^7e632a00   ds=1109d9580  dsprt=110d4c810
 0% 6774 KB, 96338 chunks: "logdef: qcopCreateLog     "  
         TCHK^7e632a00   ds=1109d9580  dsprt=110d4c810
 0% 5323 KB, 48641 chunks: "strdef: qcopCreateStr     "  
         TCHK^7e632a00   ds=1109d9580  dsprt=110d4c810
 0% 3834 KB, 97719 chunks: "chedef : qcuatc           "  
         TCHK^7e632a00   ds=1109d9580  dsprt=110d4c810
 0% 3218 KB,   6 chunks: "kgh stack                 "  
         pga heap        ds=110004990  dsprt=0

当出现ORA-04030错误的时候,Oracle会自动把出错的进程使用内存的信息给Dump出来,这里可以看到15G的内存都使用在了SQL kkoutlCreatePh上面。通过在MOS上查找,发现文档:

A Query Fails With ORA-4030 On “kkoutlCreatePh,logdef* : kkoabr” (文档 ID 1474457.1) 跟我们的Trace信息很吻合。kkoutlCreatePh引起很高的heap memory分配。而进一步根据文档指出的bug信息去查,可以查到
Bug 12907522 : EXPLAIN PLAN FOR SQL WITH LARGE INLIST CAUSES EXCESSIVE MEMORY CONSUMPTION ,可以发现如果在一个SQL语句中,含有大量的INLIST,也就是IN的语法括号中跟着一大堆的LIST的会引起过度的内存损耗。而我们的语句也是这类型的语句,IN里面含有大量的LIST值。详情可见附件。

这个SQL放到word里面长达40多页,但是后面in里面含有太多的值,符合bug 12907522的描述。同时我们看到文档中指出的堆栈是:

Explain plan for a SQL with high inlist members runs indefinitely consuming
  huge PGA (over 4G and still not finishing). Heap dump show majority memory
  consumed in -
  Call Heap -> kxs-heap-c -> kkoutlCreatePh

而我们从Trace中也发现了类似的信息。可以看到我们的Heap中的信息也是kxs-heap-c和kkoutlCreatePh。

PRIVATE HEAP SUMMARY DUMP
16 GB total:
    15 GB commented, 260 KB permanent
   496 MB free (0 KB in empty extents),
      16 GB,   1 heap:    "kxs-heap-c     "            495 MB free held
------------------------------------------------------
Summary of subheaps at depth 1
15 GB total:
    15 GB commented, 17 MB permanent
   182 KB free (16 KB in empty extents),
      15 GB,   1 heap:    "kkoutlCreatePh "

二、解决办法

知道了原因,解决办法也很简单。

1. 根据文档1474457.1的解决办法,修改“_b_tree_bitmap_plans”为false可以规避这个问题,这个参数是可以动态调整的,但是这个参数的风险是修改为false会导致系统无法生成bitmap的执行计划。不过我们对系统进行了检查,发现系统并不存在bitmap的索引,因此并无影响。但是alter system的将会导致以后如果需要建立bitmap的时候,会无法产生相应的计划,所以建议在hint上加参数来解决。

SELECT /*+ OPT_PARAM('_b_tree_bitmap_plans ' 'false') */ *

2. 根据Bug 12907522的描述,建议将SQL语句进行修改,把IN中的LIST值适当的减少。

稿源:Buddy Yuan (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 后端存储 » ORA-04030: out of process memory when trying to allocate 381096 bytes (kkoutlCreatePh,logde…

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录