ORA-600(kcbz_check_objd_typ_3)错误

客户的测试数据库升级过程中碰到了这个错误信息，简单记录一下。

 

 

在TRACE文件中的详细信息为：

ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kcbz_check_objd_typ_3], [0], [0], [1], [], [], [], []
Current SQL statement for this session:
insert into source$(obj#,line,source) values (:1,:2,:3)
check trace file d:\oracle\product\10.2.0\db_1\rdbms\trace\orcl_ora_0.trc for preloading .sym file messages
----- Call Stack Trace -----
calling              call     entry                argument values in hex     
location             type     point                (? means dubious value)    
-------------------- -------- -------------------- ----------------------------
_ksedst+38           CALLrel  _ksedst1+0           0 1
_ksedmp+898          CALLrel  _ksedst+0            0
_ksfdmp+70           CALLrel  _ksedmp+0            3
_kgerinv+140         CALLreg  00000000             8C527C8 3
_kgeasnmierr+19      CALLrel  _kgerinv+0           8C527C8 5400020 3516440 3
                                                   8FF65DC
_kcbassertb3+98      CALLrel  _kgeasnmierr+0       8C527C8 5400020 3516440 3 0 0
                                                   0 0 0 0 0 1 0
__VInfreq__kcbz_dec  CALLrel  _kcbassertbd3+0      3516440 4FC67780 0 0 1
r_wspwbcnt+1322                                    
_kcbzib+2286         CALLrel  _kcbz_check_objd_ty  8FFA504 4FC67780 1D262000 0 0
                              p+0                  1 40 0 0 50DFFCBC
_kcbgcur+6197        CALLrel  _kcbzib+0            50DFFCBC 8FFA504 8FF8D60 2 0
                                                   5D 0 0 513F49C0 0 8FF8DD8
                                                   8FF8D58
_ktbgcur+128         CALLrel  _kcbgcur+0           8FFA504 2 5D 0
_ktsfbget+181        CALLrel  _ktbgcur+0           8FFA4FC 2 5D 0
_ktsf_gsp+1086       CALLrel  _ktsfbget+0         
_kdtgsp+522          CALLrel  _ktsf_gsp+0          4D55A050 8FFA4FC 3 1 8FFA4FC
                                                   FFFF FFFF 0
_kdtgsph+342         CALLrel  _kdtgsp+0            B627884 8FFA5A8
_kdtFlushBuf+471     CALLrel  _kdtgsph+0           B627884 8FFA5A8
_insflush+340        CALLrel  _kdtFlushBuf+0       B627884
__VInfreq__insSaveC  CALLrel  _insflush+0         
nt+541                                            
_insdrvFastPath+121  CALLrel  _insrowFastPath+0    B627884 8FFAA00 0
5                                                 
_inscovexe+364       CALLrel  _insdrvFastPath+0    B627884
_insExecStmtExecIni  CALL???  00000000             4D55AE28 4D55A188 8FFB130
Engine+55                                          
_insexe+367          CALLrel  _insExecStmtExecIni  4D55AE28 4D55A188 8FFB130
                              Engine+0            
_opiexe+11573        CALLrel  _insexe+0            4D55AA84 8FFB130
_opiall0+1637        CALLrel  _opiexe+0            49 3 8FFB3DC
_opikpr+671          CALLrel  _opiall0+0           65 22 8FFB654 0 0 8FFB6FC 37
                                                   20 0 0 0 0 0
_opiodr+1306         CALLreg  00000000             65 17 8FFBEB0
_rpidrus+178         CALLrel  _opiodr+0            65 17 8FFBEB0 0
_rpidru+84           CALLrel  _rpidrus+0           8FFBA24
_rpiswu2+426         CALLreg  00000000             8FFBDF0
_kprball+1234        CALLrel  _rpiswu2+0           51B2E9D0 0 8FFBDCC 2 8FFBE2C
                                                   0 8FFBDCC 0 936F10 936FC0
                                                   8FFBDF0 8
_kqlsrcchg+426       CALLrel  _kprball+0           8FFBEB0 900
_kqlchg+1274         CALLreg  00000000             48D4E338 1 1
_kglfls1+330         CALLreg  00000000             8C527C8 48D4E338
_ktcCommitTxn+1666   CALLrel  _kglfls1+0           8C527C8 A23868
_ktdcmt+93           CALLrel  _ktcCommitTxn+0      4FA9CD64 0 0 0 0 1 0 0
                                                   3CCFA00 189
_k2lcom+98           CALLrel  _ktdcmt+0           
_k2send+1163         CALLrel  _k2lcom+0            1 8FFC4C0 0 8FFC430
_xctctl+77           CALLrel  _k2send+0            4 0 8FFC5A0 0 8FFC4C0 8FFC4C8
_xctcom_with_option  CALLrel  _xctctl+0            8FFC5A0 0
s+697                                             
_opiexe+13018        CALLrel  _xctcom_with_option  0 0
                              s+0                 
_opiosq0+7100        CALLrel  _opiexe+0            4 0 8FFCE68
_kpooprx+234         CALLrel  _opiosq0+0           3 E 8FFD030 A4 0
_kpoal8+746          CALLrel  _kpooprx+0           8FFF66C 649D0A0 5B24 1 0 A4
_opiodr+1306         CALLreg  00000000             5E 17 8FFF668
_ttcpip+990          CALLreg  00000000             5E 17 8FFF668 0
_opitsk+1102         CALL???  00000000            
_opiino+1081         CALLrel  _opitsk+0            0 0
_opiodr+1306         CALLreg  00000000             3C 4 8FFFC28
_opidrv+819          CALLrel  _opiodr+0            3C 4 8FFFC28 0
_sou2o+45            CALLrel  _opidrv+0            3C 4 8FFFC28
_opimai_real+112     CALLrel  _sou2o+0             8FFFC1C 3C 4 8FFFC28
_opimai+92           CALLrel  _opimai_real+0       2 8FFFC54
_OracleThreadStart@  CALLrel  _opimai+0           
4+726                                             
77E1A98D             CALLreg  00000000            

询问客户升级的过程，找到了问题所在。客户原始数据库是10.2.0.4 for Windows的环境，后来找了一个新的Windows环境，安装的10.2.0.5的数据库软件，因此将原始的数据库拷贝的新的环境中，需要执行升级。

这个步骤本身没有问题，问题在于，由于源数据库和目标数据库存储文件的位置发生了变化，于是客户执行了控制文件的重建操作。

利用10.2.0.5软件环境创建的控制文件，加载10.2.0.4的数据库文件执行升级操作，这种操作想不出现问题都很难，所以上面的ORA-600错误并不意外。

针对这个错误，没有必要再去分析和解决了，建议客户重新拷贝数据库文件，利用RESTORE或者RENAME的方式，然后重新执行升级操作。

由于客户只是在进行测试，最简单的办法是卸载掉10.2.0.5，安装一个一致的10.2.0.4版本的数据库，避免升级的过程。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/4227/viewspace-694962/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/4227/viewspace-694962/