【データリカバリ】ORA-600[kccpb_sanity_check_2]

 

プロのOracle Databaseの復旧サービスを提供
携帯番号: +86 13764045638 メール: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#番号がコントロールファイルより大きいだから、その関数とコントロールファイルの間にロジックが一致していないと認定している。

その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、バックアップがなければ人工的にコントロールファイルを再構造するしかない。

Comment

*

沪ICP备14014813号-2

沪公网安备 31010802001379号