这种问题的解决办法有好几种,根据数据量的大小以及业务是否允许停机的情况考虑,主要分以下几类救急办法:
一、坏块在索引上的位置判断
1.1如果坏块不多,而且坏块都在在索引比较靠前的位置(这个靠前的位置每个版本不一样,每个版本的对象数不一样),可以理解为在建库时候obj$自带索引的那个块最大地址就是属于考前的位置,当坏块在这个位置前面时候有一种比较便捷的处理方式,
就是通过创建一个一模一样的数据库,使用bbed copy(相比DD操作,操作起来超级简单又不容易出错)把对应坏块位置的块copy覆盖损坏的块,apply后即可(如果是在obj$表中的块那么记得修改下obj里对应的create time即可使数据库恢复正常,这个在前面有个案例描述过)。
1.2如果坏块是在索引靠后的位置或者坏块很多,索引的对象为后面创建的对象,那么这个时候就比较麻烦了,好在obj$的数据是完整的,
我的建议是采用2种方法,
1.2.1 采用屏蔽obj$索引的方法,具体需要修改基表,这个方法在前面文章中有描述。这个情况一般用在数据库比较大,比如数据量有几十个T,上百T或者业务不能接受长时间停机的情况
1.2.2 当数据库的数据量不大的时候,可以采用另外一种办法,使用exp来导出数据进行修复,一般这个时候exp工具是无法直接使用的,需要使用到catexp.sql这个脚本,具体的方法请查阅博客里的文章 Corruptions on OBJ$ indexes