分类目录归档：ORA-600 or ORA-7445

ORA-00604和ORA-04024错误的处理方法

发表于 2015 年 5 月 8 日 由 Lunar

一般Oracle的bootstrap index（引导表的索引和一些核心对象）都可以尝试类似方法处理，比如下面查询语句中的I_OBJxxxxx。 . 测试环境 11.2.0.3数据库： 在数据库中长开启时，不能操作一些bootstrap index，例如： 有些bootstrap索引在upgrade模式下也不可以修改，有些可以： 可以启动到升级模式，这模式数据库会自动增加一些类似屏蔽system trigger等的操作 可以执行部分bootstrage对象的操作，例如： 升级模式自动添加的参数如下： 此时，数据字典因为遭到破坏，很多相关查询等功能都失效了： 且启动时会报错ORA-00604 ORA-04024: 正常关闭数据库也关闭不了，应该是需要执行某些核心递归SQL时遇到问题了，只能shutdown abort： 然后以升级模式启动数据库，修复这些索引：. 执行迷你升级脚本进行修复： 这里我们看到SYS.I_OBJ#_INTCOL#索引为unusable，不能在升级模式下被修复 但是，10g以后，这个索引是可以通过event 38003屏蔽的： 这里我们已经修复了损坏的索引。 在此基础上，我们重新执行迷你升级脚本： 然后正常启动数据库： 删除第一次执行迷你升级脚本因为异常而中断残留在数据库中的临时索引： 至此，完美恢复！

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

ORA-00600[kfioTranslateIO03] 和ORA-00600[17090]的解决

发表于 2015 年 5 月 2 日 由 Lunar

今天玩VM，发现数据库不能启动了： 检查alert日志，报错如下： 很久没玩这个VM，隐约记得上次好像测试修改权限了 然后，根据报错查询官网： ORA-00600: internal error code, arguments: [kfioTranslateIO03], [], [], [], [], [], [], [], [], [], [], [] 果然是权限问题，因此检查相关权限并修改。 使用root： 现在启动数据库就不报错了：

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

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

ORA-00704 ORA-00604 ORA-01502 SYS.I_DEPENDENCY1损坏或者不可用

发表于 2015 年 1 月 5 日 由 Lunar

有朋友问起ORA-00704 ORA-00604 ORA-01502: index ‘SYS.I_DEPENDENCY1’ or partition of such index is in unusable state错误怎么处理。 11.2中I_DEPENDENCY1损坏的处理 I_DEPENDENCY2损坏的处理 当SYS.I_DEPENDENCY1损坏或者不可用时，就会报如下类似错误： 首先说一下，10g中的处理方式，有两种： 1，直接在10g中修复 2，使用11.2将数据库拉起来到upgrade模式，然后修复 先看一下，数据库中跟依赖关系相关的表都有哪些： 这里，我们关心的是DEPENDENCY$的索引信息，可以看到，DEPENDENCY$表存在两个索引。 这两个索引损坏时对数据库的影响是不同的，他们分别定义如下： 9i、10g、11.1以前，一些核心对象的定义就在$ORACLE_HOME/rdbms/admin/sql.bsq中。 比如tab$,obj$,ind$等等的定义都在其中。 从11.2开始，创建一些重要的核心基表的脚本仍然是sql.bsq，但是已经将各种对象的创建分类到不同的脚本： dependency$，i_dependency1和i_dependency1的定义如下（10.2和11.2没有区别）： 下面我们看一下他们使用了哪些block： 下面我们在10.2总模拟i_dependency1失效（测试环境使用10.2.0.1）： 执行alter index i_dependency1 unusable后，alert.log的信息如下： ind$的flags字段的定义（该定义可以查询基表定义，10.2中在sql.bsq，11.1以后，在dcore.bsq）： 通过对比，可以发现实际上对于ind$.flags的定义并没有改变，只是内部操作有所变化。 这些标示很有用，比如orcacle 9204有监控SYS的XXX索引的bug会导致数据库不能open，可以通过这个标示来修复。 再比如，10g以前online 创建索引中断后很麻烦，也可以通过修改这个来修复。 10.2以后可以通过dbms_repair.online_index_clean来清理索引状态。不过该功能没有记录在10.2的官方文档中（但是用desc … 继续阅读 →

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