如果自己搞不定可以找诗檀软件专业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、若没有备份，则需要手动重建控制文件了
[…] 【数据恢复】ORA-600[kccpb_sanity_check_2]一例 […]