love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

Phone:18180207355 提供专业Oracle/MySQL/PostgreSQL数据恢复、性能优化、迁移升级、紧急救援等服务

ora-08102 and col_usage$

本站文章除注明转载外,均为本站原创: 转载自love wife love life —Roger的Oracle/MySQL/PostgreSQL数据恢复博客

本文链接地址: ora-08102 and col_usage$

今天群里以网友提问说遇到ORA-08102错误,该错误报错如下:
ORA-08102: index key not found, obj# 518, file 1, block 4132 (3)
据说是在分析表时发生的,该网友的提问地址如下:shutdown时出现错误ora-08102
让网友直接drop 该index,然后重建报错:

很明显,从上述错误来看,是重复值了,不满足创建unique index的条件。该index和对于的表结构如下:

网友执行如下sql查询,发现有85条信息:

我们知道col_usage$主要是为cbo服务的,换句话说里面存的是跟统计信息相关的,准确一点说是
存的sql查询时where 条件后谓词列相关的列统计信息使用情况,正常情况下,该表的数据在数据
库shutdown immediate 或 shutdown normal模式关闭后会被purge 清空的,正因为会在shutdown
时被清空,这里也就可能会出现一些问题,不过在10g以及以后版本已经没有这个问题了,后面会
详细描述(10g以后开始数据库shutdown 不会清空col_usage$)。

我这里让网友执行SQL 如下清空col_usage$数据,然后再次创建unique index成功:

补充一下,也可以用DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO 进行对col_usage$的清理。

我在我的10g vm环境中测试,发现:

我通过查询v$sqlarea 发现了蛛丝马迹,如下了如下sql:

里面关联了X$KQFTA 和 X$KQFCO,这两个x$ 表都是跟fixed对象有关的,所以我这里断定
col_usage$的obj#非常大的对象是跟fixed对象有关。

我们可以看到col_usage$里面部分obj#非常大的一部分实际上就是x$表的相关信息。
但是上面10条多出来的信息,我还不知道是怎么回事,大家一起研究一下。

另外,10g开始,db shutdown不会purge 清理col_usage$信息,如下测试:

关于col_usage$的几篇mos文档,大家可以参考一下:
Column usage in Multi Column Index [ID 400214.1]
DBMS_STATS With METHOD_OPT =>’..SIZE auto’ May Not Collect Histograms [ID 557594.1]
Database Shutdown Immediate Takes Forever, Can Only Do Shutdown Abort [ID 332177.1]

One Response to “ora-08102 and col_usage$”

  1. Dong_2 Says:

Leave a Reply

You must be logged in to post a comment.