ITPub博客

首页 > Linux操作系统 > Linux操作系统 > ORA-7445(ksuklms)错误

ORA-7445(ksuklms)错误

原创 Linux操作系统 作者:yangtingkun 时间:2012-05-17 19:30:58 0 删除 编辑

客户的11.2.0.2 RAC环境出现了这个ORA-7445[ksuklms]错误。

 

 

错误信息为:

2012-05-10 16:25:38.561000 +08:00
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x163A] [PC:0x100A554A8, ksuklms()+392] [flags: 0x0, count: 1]
Errors in file /app/diag/rdbms/orcl/orcl1/trace/orcl1_ora_28387.trc (incident=449642):
ORA-07445: exception encountered: core dump [ksuklms()+392] [SIGSEGV] [ADDR:0x163A] [PC:0x100A554A8] [Address not mapped to object] []
Incident details in: /app/diag/rdbms/orcl/orcl1/incident/incdir_449642/orcl1_ora_28387_i449642.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
2012-05-10 16:25:40.465000 +08:00
Dumping diagnostic data in directory=[cdmp_20120510162540], requested by (instance=1, sid=28387), summary=[incident=449642].
2012-05-10 16:25:42.061000 +08:00
Sweep [inc][449642]: completed
Sweep [inc2][449642]: completed

详细错误信息为:

*** 2012-05-10 16:25:38.800
*** SESSION ID:(917.28879) 2012-05-10 16:25:38.800
*** CLIENT ID:() 2012-05-10 16:25:38.800
*** SERVICE NAME:(SYS$USERS) 2012-05-10 16:25:38.800
*** MODULE NAME:(sqlplus@ecsyhdb1 (TNS V1-V3)) 2012-05-10 16:25:38.800
*** ACTION NAME:() 2012-05-10 16:25:38.800

Dump continued from file: /app/diag/rdbms/orcl/orcl1/trace/orcl1_ora_28387.trc
ORA-07445: exception encountered: core dump [ksuklms()+392] [SIGSEGV] [ADDR:0x163A] [PC:0x100A554A8] [Address not mapped to object] []

========= Dump for incident 449642 (ORA 7445 [ksuklms()+392]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x163A] [PC:0x100A554A8, ksuklms()+392] [flags: 0x0, count: 1]
Registers:
----------
%i0: 0xffffffff7fff72e4 %i1: 0xffffffff7fff72d6 %i2: 0xffffffff7fff72ee
%i3: 0xffffffff7fff72e4 %i4: 0x0000000000000000 %i5: 0xffffffff7a6068f8
%i6: 0xffffffff7fff6a21 %fp: 0xffffffff7fff7220 %i7: 0x0000000100a54020
%l0: 0xffffffff7fff721c %l1: 0x000000038000b840 %l2: 0x00000000000019d8
%l3: 0x0000000000001670 %l4: 0x000000000000163a %l5: 0x0000000000000000
%l6: 0xffffffff7fff72d6 %l7: 0x00000000000019e0
%o0: 0x0000000000000000 %o1: 0x0000000000008343 %o2: 0x0000000000000b4a
%o3: 0xffffffff7fff72e8 %o4: 0x000000000000001a %o5: 0x0000000000000000
%o6: 0xffffffff7fff68c1 %sp: 0xffffffff7fff70c0 %o7: 0x0000000100a5546c
%g1: 0x0000000be0d2fbd8 %g2: 0x0000000000008342 %g3: 0x0000000000008342
%g4: 0x0000000000041a10 %g5: 0x0000000000000000 %g6: 0x0000000000000000
%g7: 0xffffffff7c100200
%pc: 0x0000000100a554a8 %npc: 0x0000000100a554ac %y: 0x0000000000000000
Stack info:
----------
ss_sp: 0xffffffff7e000000 ss_size: 0x0000000002000000 ss_flags: 0
Swap entries = 1
path=/dev/md/dsk/d1, size=75500789760, free=75500789760, length=147462480

*** 2012-05-10 16:25:38.814
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- Current SQL Statement for this session (sql_id=55z15wr7xssjk) -----
alter system kill session '33603,2890'

----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
ksedst1()+96         CALL     skdstdst()           FFFFFFFF7A5FD640 ?
                                                   000000000 ? 000000000 ?
                                                   00000000A ? 000000001 ?
                                                   10BD552E0 ?
ksedst()+60          CALL     ksedst1()            000000001 ? 000000001 ?
                                                   00010C1D1 ? 00010C000 ?
                                                   10C1CA000 ? 00010C1CA ?
dbkedDefDump()+2032  CALL     ksedst()             000000001 ? 10B21A000 ?
                                                   10B21AA90 ? 10C1D2000 ?
                                                   00010B000 ? 00010C1D2 ?
ssexhd()+2196        CALL     ksedmp()             000000003 ? 000000003 ?
                                                   000000B4A ? 00038000B ?
                                                   000380000 ? 000000003 ?
__sighndlr()+12      PTR_CALL ssexhd()             10C1CE000 ? BE8D30A10 ?
                                                   10B86D110 ?
                                                   FFFFFFFF7A601EF0 ?
                                                   00010C1C9 ? 0000003E8 ?
call_user_handler()  CALL     __sighndlr()         00000000B ?
+992                                               FFFFFFFF7A601EF0 ?
                                                   FFFFFFFF7A601C10 ?
                                                   1046F1AA0 ? 000000000 ?
                                                   00000000A ?
ksuklms()+392        PTR_CALL 0000000000000000     FFFFFFFF7C100200 ?
                                                   FFFFFFFF7C100200 ?
                                                   FFFFFFFF7A601C10 ?
                                                   000000009 ? 000000000 ?
                                                   000000000 ?
ksukil()+480         CALL     ksuklms()            FFFFFFFF7FFF72E4 ?
                                                   FFFFFFFF7FFF72D6 ?
                                                   FFFFFFFF7FFF72EE ?
                                                   FFFFFFFF7FFF72E4 ?
                                                   000000000 ?
                                                   FFFFFFFF7A6068F8 ?
kkyasy()+4988        CALL     ksukil()             000000000 ? 000000001 ?
                                                   AE4BE0C42 ? AE4BE0B08 ?
                                                   10529ACB0 ? 000000B4A ?
kksExecutorclmand()  CALL     kkyasy()             000000001 ?
+2244                                              FFFFFFFF7AA56F28 ?
                                                   07FFFFFFF ? 000000001 ?
                                                   000000000 ? 07FFFFFFF ?
opiexe()+13404       CALL     kksExecutorclmand()  FFFFFFFF7AA56F28 ?
                                                   00010C1E3 ? 000000004 ?
                                                   BF0F4AB10 ? 10C1CE900 ?
                                                   10C1CE4C8 ?
kpoal8()+2368        CALL     opiexe()             000000049 ? 000000003 ?
                                                   FFFFFFFF7FFFA91C ?
                                                   000000000 ? 000000000 ?
                                                   0BFFFFFFF ?
opiodr()+1428        PTR_CALL kpoal8()             00000005E ? 00000001C ?
                                                   FFFFFFFF7FFFDDD8 ?
                                                   00010C000 ? 10C1CA000 ?
                                                   000001648 ?
ttcpip()+1056        PTR_CALL opiodr()             00010A755 ? 00000001C ?
                                                   103E6CC40 ? 00010A400 ?
                                                   000001400 ? 10C1CA000 ?
opitsk()+1528        CALL     ttcpip()             000000000 ? 10A686E74 ?
                                                   10C1CA3E0 ?
                                                   FFFFFFFF7FFFDDD8 ?
                                                   FFFFFFFF7FFFC820 ?
                                                   10C1E0F98 ?
opiino()+1000        CALL     opitsk()             10A686E74 ? 10C1E63E8 ?
                                                   10C1E0DA4 ? 10C1DF0A8 ?
                                                   000000000 ? 10C1CA0A0 ?
opiodr()+1428        PTR_CALL opiino()             000002270 ? 10C1E0E20 ?
                                                   00010C000 ? 000380000 ?
                                                   0000000FC ?
                                                   FFFFFFFF7FFFF730 ?
opidrv()+1100        CALL     opiodr()             10C1E0000 ? 000000004 ?
                                                   10359CF20 ? 00010C000 ?
                                                   000001400 ? 10C1CA000 ?
sou2o()+92           CALL     opidrv()             00000003C ? 000000004 ?
                                                   FFFFFFFF7FFFF730 ?
                                                   0001EA190 ?
                                                   FFFFFFFF7AF42F10 ?
                                                   10C3D42B0 ?
opimai_real()+304    CALL     sou2o()              FFFFFFFF7FFFF708 ?
                                                   00000003C ? 000000004 ?
                                                   FFFFFFFF7FFFF730 ?
                                                   00010C000 ? 00010B800 ?
ssthrdmain()+320     PTR_CALL opimai_real()        000000000 ?
                                                   FFFFFFFF7FFFF9D8 ?
                                                   FFFFFFFF7DF3AEB8 ?
                                                   00010B800 ? 000000001 ?
                                                   000000002 ?
main()+308           CALL     ssthrdmain()         00010C000 ? 000000002 ?
                                                   00044D000 ? 100604320 ?
                                                   10C1EF000 ? 00010C1EF ?
_start()+380         CALL     main()               000000002 ?
                                                   FFFFFFFF7FFFFAE8 ?
                                                   000000000 ?
                                                   FFFFFFFF7FFFF9E8 ?
                                                   FFFFFFFF7FFFFAF8 ?
                                                   FFFFFFFF7C100200 ?

--------------------- Binary Stack Dump ---------------------

这个错误是10.2.0.4开始引入的,Oracle10.2.0.5中已经fixed了这个问题,没想到在11.2.0.2中,这个问题仍然出现。在10.2.0.4中,在RAC环境下杀掉一个会话可能导致节点的CRASH,但是11.2中,虽然出现了同样的错误,但是数据库实例并未CRASH。该问题的描述可以参考文档:Bug 7038750 - Dump (ksuklms) / instance crash [ID 7038750.8]

11.2中可以简单的忽略这个问题,而10.2.0.4环境如果碰到这个错误,除了将数据库升级到10.2.0.510.2.0.4.1以外,还可以在初始化参数文件中添加event:‘10422 trace name context forever, level 1’来避免这个错误造成实例的CRASH

最近碰到了10.2.0.4上的这个BUG,在检查MOS发现Oracle更新了这个错误的状态,在文档Bug 14024668 - ORA-7445 [ksuklms] from 'alter system kill session (non-existent)' [ID 14024668.8]中记录了11.2上的问题。

这个错误确认影响的版本为11.2.0.3Oracle11.2.0.4中确认FIXED了这个错误。

 

 

 

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

请登录后发表评论 登录
全部评论
暂无介绍

注册时间:2007-12-29

  • 博文量
    1955
  • 访问量
    10350885