日归档:2015 年 1 月 6 日

ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state

如何处理下面的错误? ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_ACCESS1’ or partition of such index is in unusable state 方法跟ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用的是一样的,这里不赘述,简单模拟损坏并修复的过程如下: I_DEPENDENCY2损坏的处理 11.2中I_DEPENDENCY1损坏的处理 例如: 相应的trace如下: 解决问题: 然后将数据库启动到限制模式,rebuild该index:

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

I_DEPENDENCY2损坏的处理

我们知道,在10.2中如果SYS.I_DEPENDENCY1损坏或者不可用时,数据库open时就会报如下类似错误: 10g中I_DEPENDENCY1损坏的处理 11.2中I_DEPENDENCY1损坏的处理 那么如果I_DEPENDENCY2有问题时,什么结果呢? 我们还是在10.2.0.1中测试: 测试结果,数据库可以正常open,但是alert后报错,显示如下: 修复的方法很简单,直接将该索引的状态设置为失效,然后rebuild,具体操作,参考ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

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

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 | 标签为 , | 留下评论