日归档：2015 年 1 月 6 日

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

发表于 2015 年 1 月 6 日 由 Lunar

如何处理下面的错误？ 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损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

我们知道，在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损坏的处理

发表于 2015 年 1 月 6 日 由 Lunar

上一篇，我们测试了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 | 标签为 , | 留下评论