客户的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开始引入的,Oracle在10.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.5或10.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.3,Oracle在11.2.0.4中确认FIXED了这个错误。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-730064/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-730064/