ORA-8104/ORA-8106的处理

最新推荐文章于 2021-04-16 14:30:37 发布

congbian2246

最新推荐文章于 2021-04-16 14:30:37 发布

阅读量229

点赞数

ORA-8104/ORA-8106的处理

【分类信息】故障处理

在生产环境下重建索引是十分危险的，一旦出现故障，将十分麻烦。所以老白很少在生产时间重建较大的索引。一旦ALTER INDEX ... REBUILD ONLINE失败，那么就可能碰到一个十分严重的问题。重新做索引重建会报ORA-8104/8106错误，导致无法重建索引。直到SMON清理了上回失败的现场才能进行重建。在10.2版本里，Oracle提供了一个 dbms_repair.online_index_clean来解决这个问题。对于9.2版本，BUG3805539曾经提出为9.2版本出一个补丁的请求，不过Oracle拒绝了这个补丁请求。所以在9.2里，只能采取下列方法来处理：

停应用，重启数据库，在SMON完成清理前不要启动应用。

有一个手工的方法有可能不需要停库，不过这个方法不是100%成功的，如果日志表比较忙就无法处理了。首先我们要了解REBUILD ONLINE失败后哪些地方受到了影响，首先ind$中这个索引的FLAGS被加上了512，另外会在这个用户下产生一张日志表sys_journal_。我们要做的工作就是清除这两个部分。

sql>update ind$ set flags=flags-512 where obj#=; /* 首先要确认flags>512如果不是，说明这个标志是正常的*/

sql>drop table .sys_journal_; /*这个步骤可能会报资源忙，因为有大量的日志正在插入，可以反复重试一下 */

在9.2.0.8下的HP-UX PA-RISC（64 BIT）和SUN SPARC环境下，是有一个补丁包，可以实现类似10.2的功能的，补丁包是7362402，这个补丁包是一个MLR，包含了bug 5597450 bug 6338480 ，其中6338480就是针对ORA-8104/8106的。安装了这个补丁包后就可以执行那个存储过程来清理了。如果那个存储过程不存在，可以通过下面的方法：

SQL> oradebug setmypid

SQL> oradebug call kdic_ext_cleanup object_id wait_for_lock

其中

object_id : 0 : cleanup 所有的

> 0 : cleanup 某个OBJECT_ID

wait_for_lock : 1 : 无法获得DML锁的时候进行重试，直到达到内部限制才失败

0 : 不重试，马上失败

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12482/viewspace-1046665/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12482/viewspace-1046665/