客户的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, osid=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了这个错误。