love wife & love life —Roger 的Oracle技术博客

Phone:18180207355 提供专业Oracle数据恢复、性能优化、迁移升级、紧急救援等服务

bootstrap$核心对象数据不一致导致ORA-08102

本站文章除注明转载外,均为本站原创: 转载自love wife & love life —Roger 的Oracle技术博客

本文链接地址: bootstrap$核心对象数据不一致导致ORA-08102

昨天准备研究11g的query cache result 特性,准备用10g的老方法来直接通过
show parameter xxxx的方式来查看隐含参数,发现下面的创建视图语句居然报错ora-08102
如下是创建视图的脚本,后面是错误:


从上面的8102错误来看,很明显是数据字典信息不一致了,也就是说该记录在ind$可能已经被清除了,
而在obj$中还存在。我们来看看obj# 39是什么对象?


对于ora-08102错误,如果是发生在index上,那么我们直接drop index然后重建就ok了。
那我们来试试直接重建会怎么样?


到这里,可能有人会问,为什么使用event 38003或migrate 模式无法rebuild 该index呢?
很简单,该index的obj# <56, 换句话说,也就是对于bootstrap$核心对象是无法通过上面 的2种方式来完成重建的。

通常来说到这个地步,如果不使用其他手段的话,那么只能使用ODU或DUL进行抽取数据然后重建数据库了。
其实对于这个问题,我们可以借助BBED来进行修复。
既然是数据不一致,那么我就想知道到底是哪儿不一致了?metalink 提供处理ora-8102的方法:

从这里来看,_NEXT_OBJECT是ok的。那么我们重点就放在TEST01上了。
到这里,看到test01,我才想起这是很久以前做关于手工构造某个由于数据字典信息不一致而引发的某个600错误
而留下的隐患。

根据前面的报错,我们找到相应的trace,发现如下信息:


这里简单的进行说明:
ncol — 表示列数目
len — 表示长度
key: ():

关于ora-08012错误,大家可以参考

OERR: ORA-8102 “index key not found, obj# %s, file %s, block %s (%s)” [ID 8102.1]

下面我们继续,既然该block有问题,那么我就dump该block。

最后尝试创建视图,发现一切正常,如下:

    分享到:
18180207355
加Q咨询