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版本的資料庫，避免升級的過程。