Oracle 9i 真是头疼,ORA-00600已经成为一个招牌错误了,虽然10g也有类似错误,但是与9i已经大不相同。
最开始做DBA的时候,对ORA-00600开始了解,当得知这是“ORACLE BUG,内核错误”之类的信息时,就已经放弃解决了。当时还好,刚回国DB组离岸没法工作,无所事事,顺便给部门里其他同事做做技术支持,纯友情支持那种,非正式工作委托。所以有时候遇到了ORA-600,直接告诉他们重装吧,哈哈。第一是懒,第二是确实没信心解决。他们以为海龟DBA就很NB,而且开始我也的确PL的解决了几个问题,所以他们什么都来找我,但事实并非如此,哥清楚,当时哥只是个入门级别。
现在没办法了,面对各种生产机各种客户,不解决等于自己砸自己饭碗。硬着头皮上吧。
这次是ORA-00600,原因很简单:一般是由于table或index的数据块有错误,通常由“select XX from tblXX”引起的。
再次吐槽9i ,数据块求求侬别错了好么。。。
通过在网上各种信息收集,去伪存真,总结了解决方法。还是想告诉大家,网上的方法,不一定且很不一定是对的,都是转来转去,第一可能有步骤遗漏,第二可能不适合你的系统,所以应用有风险,解决需谨慎。最后如何解决最好,还是要靠自己推敲。
解决思路如下:
首先这是治标不治本的方法。
1. 通过错误信息 ORA-00600 【12700】 【11350】 【712367812】,可以得到错误的obj_id和block_id。
2.通过obj_id找到出错的对象,表/index/表partition等等。
3.index 直接 rebuild应该没问题,表的话可以先rename to bak; 然后重建表,注意索引的命名; 最后insert into table select * from table_bak. 搞定。当然,重建表也可以采用exp/imp的操作,但是exp时候错误的数据块肯定也是导不出来的。
问题:这么做的风险之一是也许不只有这一个object有坏块,所以有潜在的风险;另外坏块上的数据是不会insert到新建的表上的,造成数据丢失;再有就是索引名字变了。于是我想到是否可以数据块级别修复呢?答案还没有,有会的筒子可以告诉我一下,不胜感激。
附:保险起见,可以检查所有的user表是否有错误。
表的检查
select 'analyze table afis40.'||object_name|| ' validate structure;' from dba_objects where wner='AFIS40' and object_type='TABLE';
表所有信息的检查,连带索引
select 'analyze table afis40.'||object_name|| ' validate structure cascade;' from dba_objects where wner='AFIS40' and object_type='TABLE';
数据文件的检查
dbv file='XXX.dbf' blocksize=8192
但是数据文件错误信息怎么定位,怎么修复,并不清楚,欢迎赐教。
当前位置: 数据库>oracle
ORA-00600 12700的解决
来源: 互联网 发布时间:2017-05-10
本文导语: Oracle 9i 真是头疼,ORA-00600已经成为一个招牌错误了,虽然10g也有类似错误,但是与9i已经大不相同。最开始做DBA的时候,对ORA-00600开始了解,当得知这是“ORACLE BUG,内核错误”之类的信息时,就已经放弃解决了。当时还好,刚回...