客户数据库出现ORA-7445(xsStkPurge)错误。
数据库告警日志出现如下的错误信息：
Fri Aug 3 17:10:03 2012 Errors IN file /ora/app/oracle/admin/ORCL/udump/orcl_ora_23101.trc: ORA-07445: exception encountered: core dump [xsStkPurge()+73] [SIGSEGV] [Address NOT mapped TO object] [0x0] [] [] ORA-04030: OUT OF process memory WHEN trying TO allocate 8184 bytes (OLAP stack hea,OLAP Stack Seg) Fri Aug 3 17:10:19 2012 Errors IN file /ora/app/oracle/admin/ORCL/udump/orcl_ora_23101.trc: ORA-04030: OUT OF process memory WHEN trying TO allocate 8156 bytes (callheap,kdbmal allocation) ORA-07445: exception encountered: core dump [xsStkPurge()+73] [SIGSEGV] [Address NOT mapped TO object] [0x0] [] [] ORA-04030: OUT OF process memory WHEN trying TO allocate 8184 bytes (OLAP stack hea,OLAP Stack Seg) |
对应的TRACE文件详细信息为：
*** 2012-08-03 17:10:03.098 ksedmp: internal OR fatal error ORA-07445: exception encountered: core dump [xsStkPurge()+73] [SIGSEGV] [Address NOT mapped TO object] [0x0] [] [] ORA-04030: OUT OF process memory WHEN trying TO allocate 8184 bytes (OLAP stack hea,OLAP Stack Seg) CURRENT SQL statement FOR this SESSION: BEGIN :1 := dbms_aw.interp(:2); END; ----- PL/SQL Call Stack ----- object line object handle NUMBER name 0x9b6ad21c 93 package body SYS.DBMS_AW 0x9b6ad21c 180 package body SYS.DBMS_AW 0x9b58b904 1 anonymous block ----- Call Stack Trace ----- calling CALL entry argument VALUES IN hex location TYPE point (? means dubious VALUE) -------------------- -------- -------------------- ---------------------------- ksedst()+27 CALL ksedst1() 1 ? 1 ? ksedmp()+557 CALL ksedst() 1 ? 8168FB8 ? B748BF3C ? A9A650 ? 10 ? B7491D38 ? ssexhd()+882 CALL ksedmp() 3 ? B3F831F ? 74537378 ? 7275506B ? 29286567 ? 33372B ? xsStkPurge()+73 signal 00000000 B ? B748DC90 ? B748DD10 ? xsStkPop()+48 CALL xsStkPurge() BDAFBA7C ? B63CC640 ? B63CC644 ? 1 ? xsPMTSETUP()+2213 CALL xsStkPop() BDAFBA7C ? 12EB2 ? 0 ? B61D1528 ? B471A440 ? 0 ? xsPMTRST()+223 CALL xsPMTSETUP() B63B70DC ? B60FE628 ? A933EDF0 ? 0 ? xsINTERP()+1135 CALL 00000000 B63B70DC ? B63CA66C ? BFFF9018 ? xsILPXEQ()+4347 CALL xsINTERP() B63B70DC ? BFFF9018 ? BFFF8A84 ? 1C6 ? 0 ? B621ED28 ? xsILPCALL()+2621 CALL xsILPXEQ() CCF04F0 ? B2CFAD5 ? B63B70DC ? B60ED380 ? B63DA8C4 ? . . . opiodr()+985 CALL 00000000 3C ? 4 ? BFFFF800 ? opidrv()+466 CALL opiodr() 3C ? 4 ? BFFFF800 ? 0 ? sou2o()+91 CALL opidrv() 3C ? 4 ? BFFFF800 ? opimai_real()+117 CALL sou2o() BFFFF7E4 ? 3C ? 4 ? BFFFF800 ? main()+111 CALL opimai_real() 2 ? BFFFF830 ? __libc_start_main() CALL 00000000 2 ? BFFFF8F4 ? BFFFF900 ? +211 A8F1D6 ? BC7FF4 ? 0 ? --------------------- Binary Stack Dump --------------------- |
根据MOS的查询，只有文章Bug 6755052 : ORA-7445 [XSSTKPURGE()+73] [SIGSEGV] IN EPB WHEN DISTRIBUTING DOCUMENTS与之最为接近。应该的版本同为10.2.0.3，可以确认的是导致ORA-7445错误的主要原因还是ORA-4030错误。而且文档和当前问题的一个重要相同点在于，二者都是32位系统。
由于32位数据库的限制，SGA的大小只有1.7G，而SHARED_POOL只有300M左右，STREAMS_POOL更是只有16M，这就导致了Oracle在处理一些复杂的组件时，很容易出现内存不足的情况。
从问题时刻的AWR分析，TOP 5中出现了明显的Streams AQ: enqueue blocked on low memory等待，这个等待只出现了1次但是经历了293秒，说明STREAMS_POOL空间不足，且数据库在尝试给STREAMS_POOL分配更多空间时报错。
客户主机拥有16G内存，那么这个问题的最有限的方法就是重建64位数据库环境，彻底避免该问题的产生。