Email: [email protected] 7 x 24 online support!
ORA-00600: 内部エラー・コード, 引数: [kccpb_sanity_check_2]
プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：[email protected]
ORA-00600: 内部エラー・コード, 引数: [kccpb_sanity_check_2]
kccpb_sanity_check_2カーネル関数kernel functionがコントロールファイルの健康を確保する。そのORA-600[kccpb_sanity_check_2]が一般的にalter database mount段階で起こる； そのORA-600[kccpb_sanity_check_2]が起こる原因はコントロールファイル件controlfileブロックヘッダのseq#番号がコントロールファイルより大きいだから、その関数とコントロールファイルの間にロジックが一致していないと認定している。
そのkccpb_sanity_check_2関数は10gR2から導入された。つまり、9iにはこのようなコントロールファイル健康性検証など存在していない。lost writeとstale readを検出するために、その機能を導入した。
一般的にそのORA-600[kccpb_sanity_check_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するときにエラになっていないことを気づき、一つのコントロールファイルがトラブルが起きたと確認できる。故に、ddでコピすればいい。
このインスタンスmount段階のORA-600[kccpb_sanity_check_2]エラに対して、いくつの解決策もある：
1、コントロールファイルがいろんなパスに使われた場合に、すべてのコントロールファイルもこわれたとは限らない。control_filesバラメタを変更することで、一つ一つに試してください。無傷なコントロールファイルとこわれたコントロールファイルと一緒にcontrol_filesバラメタに存在している場合に、mountができなくなる。
2、バックアップから健全なコントロールファイルをrestoreする
3、バックアップがなければ人工的にコントロールファイルを再構造するしかない。
プロのOracle Databaseの復旧サービスを提供
携帯番号： +86 13764045638 メール：[email protected]
kccpb_sanity_check_2カーネル関数kernel functionがコントロールファイルの健康を確保する。そのORA-600[kccpb_sanity_check_2]が一般的にalter database mount段階で起こる； そのORA-600[kccpb_sanity_check_2]が起こる原因はコントロールファイル件controlfileブロックヘッダのseq#番号がコントロールファイルより大きいだから、その関数とコントロールファイルの間にロジックが一致していないと認定している。
そのkccpb_sanity_check_2関数は10gR2から導入された。つまり、9iにはこのようなコントロールファイル健康性検証など存在していない。lost writeとstale readを検出するために、その機能を導入した。
一般的にそのORA-600[kccpb_sanity_check_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するときにエラになっていないことを気づき、一つのコントロールファイルがトラブルが起きたと確認できる。故に、ddでコピすればいい。
このインスタンスmount段階のORA-600[kccpb_sanity_check_2]エラに対して、いくつの解決策もある：
1、コントロールファイルがいろんなパスに使われた場合に、すべてのコントロールファイルもこわれたとは限らない。control_filesバラメタを変更することで、一つ一つに試してください。無傷なコントロールファイルとこわれたコントロールファイルと一緒にcontrol_filesバラメタに存在している場合に、mountができなくなる。
2、バックアップから健全なコントロールファイルをrestoreする
3、バックアップがなければ人工的にコントロールファイルを再構造するしかない。