oracle索引问题，删除再重建索引与索引分析

Posted 2023-04-24

我有一个表，例如test，不是分区表，大概每个月存储四五十万的数据，里面只保存最新四个月的数据。每次清除一个月数据后我都会进行一下表分析和索引分析；每月初会插入新的四五十万数据，当然是每一万或者五千一提交的。现在的问题是，我发现这个插入过程，他们的设计是先drop掉索引（共7个索引），然后插入数据完毕后create索引，每次create这7个索引用时都特别长，大概需要三四个小时。现在我想问能不能优化，为什么采取drop又重建我已不能追问了，我想改成插入前不drop，插入后进行表分析和索引分析，不知道可不可行，会不会节省时间？哪位大侠能解答一下，感激不尽

1. 应该是可行的， 具体 会不会节省时间 试一下就可以了。

2. 大概每个月存储四五十万的数据，里面只保存最新四个月的数据

每次create这7个索引用时都特别长，大概需要三四个小时；

200万的数据，重建索引花费的时间太长了；很奇怪。

3. 估计之前的 先drop掉索引，然后插入数据完毕后create索引 也是为了避免 插入数据时，索引对插入效率的影响。追问

我记错了，一个月数据有六百万左右，所以四个月数据还是很多的，由此重建索引时间三四个小时也正常么？看了你的分析第三点，你说他设计成先drop索引也是由一定道理的呗？这个东西我不能随便试，因为挺重要的，如果本身这样先drop然后插入数据，然后重建索引是有道理的话，那我们就只能等这些时间

追答

两三千万的数据重建7个索引，差别不大了，稍微有点多，当然这个也和 索引定义、硬件条件等相关。

两三千万的数据 表分析和索引分析 我不清楚需要多少时间。

但是600万的数据提交，估计也差不多要 几十分钟吧，这个也同样 和 索引定义、硬件条件等相关。

参考技术A 重建的过程实际上是梳理索引数据的过程，有助于提高索引效率，表分析的话只是提高了数据解析效率，比如在有索引的情况下，在数据库执行sql时一般会调用索引，但是如果在进行解析时数据库认为不调用索引效率更高那么就会进行全表扫描。表分析实际上是增加了解析过程的准确性，但是对索引检索效率提高有限，真正要提高索引效率的话还是重建更直接。当然了定期进行表分析也是必须的。
当然，如果系统io有瓶颈的话，那么先删除索引就更有必要了。 在插入数据过程中，索引也是需要消耗io资源的。追问

谢谢你的回答

ORACLE关于索引是否需要定期重建争论的整理

     ORACLE数据库中的索引到底要不要定期重建呢？ 如果不需要定期重建，那么理由是什么？ 如果需要定期重建，那么理由又是什么？另外，如果需要定期重建，那么满足那些条件的索引才需要重建呢？关于这个问题，网上也有很多争论，也一直让我有点困惑，因为总有点不得庐山真面目的感觉，直到上周看到了一些资料，遂整理于此，方便以后翻阅：

 

首先来看看网上关于索引需要重建的准则或标准：

   一：分析(analyze)指定索引之后，查询index_stats的height字段的值，如果这个值>=4 ,最好重建（rebuild）这个索引。虽然这个规则不是总是正确，但如果这个值一直都是不变的，则这个索引也就不需重建。

　　二：在分析(analyze)指定索引之后，查询index_stats的del_lf_rows和lf_rows的值,如果(del_lf_rows/lf_rows)*100 > = 20，则这个索引也需要重建。

 

关于这个论据，我们找到可以考证的官方资料为Various Aspects of Fragmentation (文档 ID 186826.1) ，其中有这么一段

Along with the REBUILD clause of the ALTER INDEX, Oracle8i introduces the

COALESCE clause as another way to address fragmentation issues.

 

In the following cases, it may be worthwhile to rebuild the index:

--> the percentage of the space used is bad - lower than 66%: PCT_USED

--> deleted leaf blocks represent more than 20% of total leaf blocks: DEL_LF_ROWS

--> the height of the tree is bigger than 3: HEIGHT or BLEVEL

 

另外网上还有一些关于重建索引的理由或说法，大概有这么一下（有可能不全），如下所示：

    1、Oracle的B树索引随着时间的推移变得不平衡(错误的认识)

    2、索引碎片在不断增加

    3、索引不断增加，删除的空间没有重复使用（错误的认识）

    4、索引 clustering factor （集群因子）不同步，可以通过重建修复(错误的认识)

 

但是这个资料非常古老了，是Oracle 8i， Oracle 9i时代的资料，当然对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20%需要重建索引的准则，这种说法显然也没有过时，但是关于PCT_USED低于66%的就建议重建索引，这种说法对现在主流版本有点不合时宜。关于这些，其实ORACLE官方文档有关于索引重建的必要性和影响的讨论， 官方文档为索引重建的必要性与影响 (文档 ID 1525787.1)

---------------------------------------------------------------------------------------------------------------------

适用于:

 

Oracle Database - Enterprise Edition - 版本 8.1.7.0 和更高版本

本文档所含信息适用于所有平台

 

用途

 

本文章将重点概述重建索引的各种影响。我们通常会定期重建索引，但事实上，判断索引重建是否有用一般并不以统计数字为基础，而且很少保留索引的重建历史记录。

 

适用范围

本文章的目标受众是数据库管理员。

 

详细信息

关于重建索引有用与否的讨论有很多。一般而言，极少需要重建 B 树索引，基本原因是 B 树索引很大程度上可以自我管理或自我平衡。

认为需要重建索引的最常见理由有：

- 索引碎片在不断增加

- 索引不断增加，删除的空间没有重复使用

- 索引 clustering factor （群集因子）不同步

事实上，大多数索引都能保持平衡和完整，因为空闲的叶条目可以重复使用。插入/更新和删除操作确实会导致索引块周围的可用空间形成碎片，但是一般来说这些碎片都会被正确的重用。

Clustering factor 群集因子可以反映给定的索引键值所对应的表中的数据排序情况。重建索引不会对群集因子产生影响，要改变集群因子只能通过重组表的数据。

另外，重建索引的影响非常明显，请仔细阅读以下说明：

 

1. 大多数脚本都依赖 index_stats 动态表。此表使用以下命令填充：

analyze index ... validate structure;

尽管这是一种有效的索引检查方法，但是它在分析索引时会获取独占表锁。特别对于大型索引，它的影响会是巨大的，因为在此期间不允许对表执行 DML 操作。虽然该方法可以在不锁表的情况下在线运行，但是可能要消耗额外的时间。

 

2. 重建索引的直接结果是 REDO 活动可能会增加，总体的系统性能可能会受到影响。

插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。重建索引后，它将连接的更为紧凑；但是，随着对表不断执行 DML 操作，必须再次分割索引，直到索引达到平衡为止。结果，重做活动增加，且索引分割更有可能对性能产生直接影响，因为我们需要将更多的 I/O、CPU 等用于索引重建。经过一段时间后，索引可能会再次遇到“问题”，因此可能会再被标记为重建，从而陷入恶性循环。因此，通常最好是让索引处于自然平衡和（或）至少要防止定期重建索引。

 

3. 通常是优先考虑index coalesce（索引合并），而不是重建索引。索引合并有如下优点：

- 不需要占用近磁盘存储空间 2 倍的空间

- 可以在线操作

- 无需重建索引结构，而是尽快地合并索引叶块，这样可避免系统开销过大，请见第 2 点中的解释。

注意：例如，如要将索引转移到其他表空间，则需要重建索引。

 

综上所述，强烈建议不要定期重建索引，而应使用合适的诊断工具。请参阅以下文章，其中列出了可用于分析索引结构的脚本。它不使用“analyze index validate structure” 命令，但将基于当前表和索引统计信息来估计索引大小。

Note 989186.1- Script to investigate a b-tree index structure

 

看了上面官方文档，想必你已经对索引是否需要定期重建有了一个认识,但是，你是否总觉得这是一个结论性的说法，总觉得不够深入，例如Oracle索引为什么会自我平衡，自我管理呢？为什么那些被删除的索引空间会被重复使用？ 为什么大部分B树索引不需要重建呢? 等等诸如此类的疑问，那么下面这哥们这篇文章（index-internals-rebuilding-the-truth）关于这方面的分析、介绍，绝对是我见过最详细、最深入介绍索引内部的知识。如果链接查看不了,请从附件下载index-internals-rebuilding-the-truth.pdf 。剩下的就是反复通读、深入理解、体会了！

 

参考资料：

https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=529590097581429&id=1525787.1&_afrWindowMode=0&_adf.ctrl-state=mztcpsxax_149
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=529957019657481&id=1525787.1&_afrWindowMode=0&_adf.ctrl-state=mztcpsxax_198
http://www.it-matters.be/doc/index-internals-rebuilding-the-truth.pdf
https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=531414583432488&id=186826.1&displayIndex=1&_afrWindowMode=0&_adf.ctrl-state=mztcpsxax_247