7 x 24 在线支持!
ORA-00600: 内部错误代码, 参数:[kccpb_sanity_check_2]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 : 13764045638 QQ号:47079569 邮箱:service@parnassusdata.com
kccpb_sanity_check_2内核函数kernel function负责监测控制文件的健康性,该ORA-600[kccpb_sanity_check_2]一般在alter database mount阶段发生; 该ORA-600[kccpb_sanity_check_2]发生的原因一般是 控制文件controlfile 块头的seq#号大于控制文件头中的seq#,所以该监测函数认为存在控制文件逻辑不一致。
该kccpb_sanity_check_2函数是从10gR2才引入了,换句话说9i没有这样的控制文件健康性监测,引入该特性的目的是为了检测出写丢失lost write和陈旧读stale read。
该ORA-600[kccpb_sanity_check_2]一般有2个argument代码:
ARGUMENTS:
Arg [a] seq# in control block header.
Arg [b] seq# in the control file header.
Arg [c] maclean
ksedmp: internal or fatal error ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [53672], [53643], [0x000000000], [], [], [], [] Current SQL statement for this session: ALTER DATABASE MOUNT ----- Call Stack Trace ----- calling call entry argument values in hex location type point (? means dubious value) -------------------- -------- -------------------- ---------------------------- ksedst+001c bl ksedst1 000000000 ? 700000010007FE0 ? ksedmp+0290 bl ksedst 104C1FCD0 ? ksfdmp+02d8 bl 03F34734 kgerinv+00dc bl _ptrgl kgeasnmierr+004c bl kgerinv 1105312C0 ? 110211598 ? 000000000 ? 000015018 ? 000000000 ? kccpb_sanity_check+ bl kgeasnmierr 11019B7D0 ? 1104A0040 ? 013c 104DFF150 ? 300000003 ? 000000000 ? 00000D1A8 ? 000000000 ? 00000D18B ? kccbmp_get+00f8 bl kccpb_sanity_check FFFFFFFFFFFFFFFF ? 2700000027 ? kccsed_rbl+008c bl kccbmp_get 1100745A0 ? 104E02124 ? kccocx+08fc bl kccsed_rbl 100000068 ? kccocf+0140 bl kccocx FFFFFFFFFFEB7C8 ? 0CBC08BD8 ? 16D694B2F ? 110231D90 ? kcfcmb+0ab4 bl kccocf 000000000 ? 000000000 ? 000000002 ? 10041C1F4 ? kcfmdb+0054 bl kcfcmb 0FFFED160 ? 7000000B9FF038E ? 000000003 ? 000000000 ? 000000003 ? 000000000 ? 000000000 ? 000000000 ? adbdrv+06c0 bl kcfmdb 110262390 ? 7000000BCFFA050 ? 7000000BCFFA470 ? 104F38E08 ? opiexe+2d34 bl adbdrv opiosq0+1ac8 bl opiexe 000000001 ? 000000000 ? FFFFFFFFFFF9148 ? kpooprx+016c bl opiosq0 300000020 ? 110231D90 ? 7000000BD1038F8 ? A400011019B7D0 ? 000000000 ? kpoal8+03cc bl kpooprx FFFFFFFFFFFB954 ? FFFFFFFFFFFB700 ? 1600000016 ? 100000001 ? 000000000 ? A40000000000A4 ? 000000000 ? 1103ABA18 ? opiodr+0b2c bl _ptrgl ttcpip+1020 bl _ptrgl opitsk+117c bl 01FC6908 opiino+09d0 bl opitsk 1EFFFFD920 ? 000000000 ? opiodr+0b2c bl _ptrgl opidrv+04a4 bl opiodr 3C102A89D8 ? 404C72CF0 ? FFFFFFFFFFFF8E0 ? 0102A89D0 ? sou2o+0090 bl opidrv 3C02A2895C ? 400000020 ? FFFFFFFFFFFF8E0 ? opimai_real+01bc bl 01FC3174 main+0098 bl opimai_real 000000000 ? 000000000 ? __start+0090 bl main 000000000 ? 000000000 ? last wait for 'control file sequential read' wait_time=0.000511 sec, seconds since wait started=0 file#=0, block#=27, blocks=1 blocking sess=0x0 seq=23 Dumping Session Wait History for 'control file sequential read' count=1 wait_time=0.000511 sec file#=0, block#=27, blocks=1 for 'control file sequential read' count=1 wait_time=0.000957 sec file#=0, block#=1, blocks=1 for 'CSS operation: action' count=1 wait_time=0.036477 sec function_id=41, =0, =0 for 'CSS operation: action' count=1 wait_time=0.000200 sec function_id=41, =0, =0 for 'CSS initialization' count=1 wait_time=0.060291 sec =0, =0, =0 for 'control file sequential read' count=1 wait_time=0.000547 sec file#=0, block#=1, blocks=1 for 'control file sequential read' count=1 wait_time=0.003763 sec file#=0, block#=3, blocks=20 for 'control file heartbeat' count=1 wait_time=3.906271 sec =0, =0, =0 for 'control file sequential read' count=1 wait_time=0.020452 sec file#=0, block#=3, blocks=20 for 'control file sequential read' count=1 wait_time=0.000310 sec file#=0, block#=1, blocks=1
上例是一个ORA-600[kccpb_sanity_check_2]的实战案例,虽然出现了该错误,但是由于多路复用了controlfile控制文件,通过修改参数control_files ,发现其中第二个控制文件mount时未报错,可以确信仅有1个控制文件有问题,所以只需要dd 复制一下即可。
针对这个 实例mount阶段的ORA-600[kccpb_sanity_check_2]错误,一般有几种解决方法:
1、如果多路复用了控制文件,则未必所有控制文件都坏了,修改control_files参数一个个试过来,注意当 好的控制文件和坏的控制文件都在参数control_files里时是无法mount成功的
2、从备份中restore健康的控制文件出来
3、若没有备份,则需要手动重建控制文件了