0

ORA-07445: [xsStkPurge()+73]

老杨 2019-03-26
64
摘要:客户数据库出现ORA-7445(xsStkPurge)错误。数据库告警日志出现如下的错误信息:FriAug317:10:032012Err...

问题描述

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

「喜欢文章,快来给作者赞赏墨值吧」

评论

0
0
最新发布
暂无内容,敬请期待...
数据库资讯
最新 热门 更多
本月热门
近期活动
全部
暂无活动,敬请期待...
相关课程
全部
暂无课程,敬请期待...