ORA-600[kcbz_check_objd_typ]錯誤處理

ORA-600[kcbz_check_objd_typ]錯誤處理

基本要素
有渠道反饋，HIS軟體在對資料進行儲存的時候，提示ORA-600錯誤，具體的錯誤資訊如下：

[Microsoft][ODBC driver forOracle][Oracle]ORA-20999: ORA-00600: 內部錯誤碼, 參數:[kcbz_check_objd_typ], [0], [0], [1], [], [], [], [], [], [], [], []

ORA-06512: 在"ZLHIS.ZL_ERRORCENTER", line 73

ORA-06512: 在 "ZLHIS.ZL_病人XX列印_UPDATE",line 231

ORA-06512: 在 line 1

        該錯誤無法跳過，導致業務無法正常運行。

問題分析
步驟一：按提示分析‘預存程序’
        按理這個提示還是比較明確，根據經驗判斷可能是ZL_病人XX列印_UPDATE可能有問題，結合ORA-06512錯誤，嘗試重建該過程和同義字，執行了以上操作問題依舊。

步驟二：分析ora-600錯誤
        接著分析下ORA-600[kcbz_check_objd_typ]錯誤，該錯誤按照百度上的解釋是由於Oracle在檢查記憶體中的資料區塊時,探索資料塊上的對象號是錯誤的，拋出該錯誤提示，進一步分析問題，發現是在訪問【病人XX列印】表的時候拋出的錯誤，我們單獨對該表進行分析，我們對該表進行全表查詢的時候，提示ora-08103錯誤，但是如果只查詢部分表，則查詢正常。

       

但是其實該對象是存在的，如下：

        我們再對該表的結構進行排查，發現該表的索引都是BIN$類似的名稱，證明該表是通過閃回方式進行了恢複操作，這裡我們終於定位了問題的所在。

        問題產生的根本原因就是因為操作員誤操作，對病人護理列印表進行了drop操作，然後用閃回方式進行了恢複，但是因為某些原因，可能導致資料恢複了，但是資料庫字典表相關內容出現了錯誤（或者叫不匹配），這樣就導致資料庫對該表做任何操作，都會提示錯誤，如我們對ZLHIS使用者進行統計資訊收集，同樣會得到如下提示：

解決過程
步驟一：對錯誤表重新命名，建立一張同名的表
        通過rename操作，對【病人XX列印】表進行重新命名，然後重建立一張【病人XX列印】表，通過插入語句，將資料插入新的表中，這裡我們要注意，因為舊錶訪問有問題，因此我們得用迴圈插入的方式操作，如下：

l  重新命名表

rename 病人XX列印 to病人XX列印_原始

l  先建立一張新表

create table病人XX列印 as select * from病人XX列印_原始 where 1=2

/

步驟二：通過過程將原始表的資料插入到新表中
        在插入的時候，我們無法通過全表掃描訪問訪問原始表，但是幸運的時候，可以通過全表訪問ROWID,我們就建立一張表保持原始表的ROWID，然後通過匹配ROWID逐條插入到新表中，如下

l  先建立一張儲存rowid的表

create table病人XX列印_rowid asselect rowed from病人XX列印_原始

l  過程逐條插入

begin
  for cursor_rowid in (select rrowid  from 病人XX列印_rowid)loop
  begin
    insert into 病人XX列印  select *from 病人XX列印_原始 where rowid=CHARTOROWID(cursir_rowid.rrowid);
    commit;
end;
end loop;
end;
/

        通過以上操作，最後有接近30條記錄無法轉移到新表，不過不影響使用。