ORA-0060012700的解决

Oracle 9i 真是头疼，ORA-00600已经成为一个招牌错误了，虽然10g也有类似错误，但是与9i已经大不相同。最开始做DBA的时候，对ORA

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
但是数据文件错误信息怎么定位，怎么修复，并不清楚，欢迎赐教。