标签归档:i_dependency1

11.2中I_DEPENDENCY1损坏的处理

上一篇,我们测试了10.2中,i_dependency1失效的过程和处理方法。 参考10g中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 这里,我们在11.2中模拟i_dependency1失效(测试环境使用11.2.0.3): 11.2中:先看一下,数据库中跟依赖关系相关的表都有哪些: 可以看到,10g是18个,11.2是24个。 10g和11g中,DEPENDENCY$表都存在两个索引,这两个索引损坏时对数据库的影响是不同的,他们分别定义如下: 他们存储在哪些block中: 10g和11g的DEPENDENCY$ 和 I_DEPENDENCY1、I_DEPENDENCY2定义都一致的,只是处理方法不同。 现在我们在11.2.0.3模拟i_dependency1失效,看看什么效果: 相应的alert.log信息如下: 说明已经标示 SYS.I_DEPENDENCY1 为无效了。 现在启动数据库看看: 没错,就是这个结果,从11.2开始,类似I_DEPENDENCY1这样的index的失效不会数据库不能open了。 而在10.2中,需要open upgrade模式。 现在修复这个索引: 注意 :11.2跟10.2还有一个小区别(感觉无关紧要):11.2多取了一个字段“type#”: 那么11.2为什么可以直接open呢? 首先,我们来看一下,当 I_DEPENDENCY1 正常时,数据库open的相关动作: 该语句执行7次,七次的执行计划都是上面这样的。 当I_DEPENDENCY1为UNUSABLE时,该语句仍然执行7次,但是7次的执行计划都类似下面的,走“TABLE ACCESS FULL DEPENDENCY$”。 这说明oracle 11.2的二进制代码多了一个判断的功能,当发现I_DEPENDENCY1为UNUSABLE时自动修改了执行计划(没有验证其他类似索引是否都是这样的): 推测:11.2的代码里面写死了一个判断当open数据库时,如果遇到类似DEPENDENCY$这样的表的索引失效了,那么直接对DEPENDENCY$进行全表扫描。

发表在 backup&recovery, ORA-600 or ORA-7445 | 标签为 , | 留下评论