ORA-7445(xsStkPurge)错误

最新推荐文章于 2024-03-17 22:10:26 发布

ckawt40802

最新推荐文章于 2024-03-17 22:10:26 发布

阅读量119

点赞数

文章标签：数据库

客户数据库出现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位数据库环境，彻底避免该问题的产生。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-742478/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-742478/