当前位置:Gxlcms > mysql > ORA-600[kcbz_check_objd_typ]错误处理

ORA-600[kcbz_check_objd_typ]错误处理

时间:2021-07-01 10:21:17 帮助过:36人阅读

有渠道反馈,HIS软件在对数据进行保存的时候,提示ORA-600错误,具体的错误信息如下:[Microsoft][ODBC driver forOracle][Oracl

基本要素
有渠道反馈,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错误,但是如果只查询部分表,则查询正常。

ORA-600[kcbz_check_objd_typ]错误处理

但是其实该对象是存在的,如下:

ORA-600[kcbz_check_objd_typ]错误处理

我们再对该表的结构进行排查,发现该表的索引都是BIN$类似的名称,证明该表是通过闪回方式进行了恢复操作,这里我们终于定位了问题的所在。

问题产生的根本原因就是因为操作员误操作,对病人护理打印表进行了drop操作,然后用闪回方式进行了恢复,但是因为某些原因,可能导致数据恢复了,但是数据库字典表相关内容出现了错误(或者叫不匹配),这样就导致数据库对该表做任何操作,都会提示错误,如我们对ZLHIS用户进行统计信息收集,同样会得到如下提示:

ORA-600[kcbz_check_objd_typ]错误处理

解决过程
步骤一:对错误表重命名,新建一张同名的表
通过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条记录无法转移到新表,,不过不影响使用。

本文永久更新链接地址

人气教程排行