难道是rebuild index的一个bug?

今天在分析一条语句的时候,一个表也就10来行记录,segment的大小也就5M,通过查看其执行计划,发现是走索引的,但是却有5000多的cr。奇怪,之前表刚刚做过move tablespace and rebuild index,按理说rebuild index之后,10来行记录的cr不会有5000多呀!

测试了一下加个full的hints,发现cr才20多。难道是gather table stats的信息有问题?再次收集一次,还是和原来一样,用analyze收集一次,也是一样,blevel是0,leaf block也很少。这么少的block走索引产生5000多的cr,真的有问题呀。

用treedump把index dump出来看看:alter session set events ‘immediate trace name treedump,level object_id’;检查发现原来实际的leaf block要比之前收集到的统计信息多很多,而且也有2个branch!!

看来原因就在这里了,index在rebuild之后,可能状态已经恢复了valid,但是block还没有重组,虽然分析之后的统计信息能看到,但是这个信息是不准确的,此时一定要通过treedump来观察实际的leaf block和blevel。难道,这是一个rebuild index的bug么?

最后,通过drop index and create index解决该问题。看执行计划是走索引,也只有20多的cr了。

相关文章

4条评论

  1. re 玉面飞龙:
    从分析之后的统计信息来看,是新的;但是从treedump的信息来看,rebuild index似乎没有生效,branch还有2个。SQL走索引,cr的消耗和rebuild index之前的一样。

  2. 请教一下,是不是所有的Rebuild Index 都会有这样的问题啊,因为Tablespace调整,重做了很多Index,会不会都有问题啊?

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据