Oracle索引重建

一、前言

Oracle建议对于索引深度超过4级以及已删除的索引条目至少占有现有索引条目总数的20% 这2种情形下需要重建索引。有人持不同观点，就是强烈建议不要定期重建索引。索引重建是一个争论不休被不断热烈讨论的议题。

1、重建索引的理由

    a、Oracle的B树索引随着时间的推移变得不平衡(误解)

    b、索引碎片在不断增加

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

d、索引 clustering factor （集群因子）不同步，可以通过重建修复(误解)

2、反对重建索引的理由

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

        analyze index ... validate structure;

       尽管这是一种有效的索引检查方法，但是它在分析索引时会获取独占表锁。对于大型索引，其影响会是巨大的，因为在此期间不允许对表执行DML 操作。

       虽然该方法可以在不锁表的情况下在线运行，但是可能要消耗额外的时间。

    b、重建索引的直接结果是 REDO 活动可能会增加，总体系统负载也可能会提高。

       插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。

       重建索引后，它将连接的更为紧凑；但是，随着对表不断执行 DML 操作，必须再次分割索引，直到索引达到平衡为止。

       结果，重做活动增加，且索引分割更有可能对性能产生直接影响，因为我们需要将更多的 I/O、CPU 等用于索引重建。

       经过一段时间后，索引可能会再次遇到"问题"，因此可能会再被标记为重建，从而陷入恶性循环。

       因此，通常最好是让索引处于自然平衡和（或）至少要防止定期重建索引。

3、Oracle的最终建议

    一般而言，极少需要重建 B 树索引，基本原因是 B 树索引很大程度上可以自我管理或自我平衡。

    大多数索引都能保持平衡和完整，因为空闲的叶条目可以重复使用。

    插入/更新和删除操作确实会导致索引块周围的可用空间形成碎片，但是一般来说这些碎片都会被正确的重用。

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

    强烈建议不要定期重建索引，而应使用合适的诊断工具。

    个人结论，如果重建索引的巨大工作量与之对应的是极小的收益，那就得不偿失。如果系统有可用空闲期，重建之前和之后的测量结果表明性能有提高，值得重建。

4、改良方法

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

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

       b、可以在线操作

       c、无需重建索引结构，而是尽快地合并索引叶块，这样可避免系统开销过大。

5、真正需要重建索引的情形

    索引或索引分区因介质故障损坏

    标记为UNUSABEL的索引需要重建

    索引移动到新的表空间或需要改变某些存储参数

    通过SQL*Loader加载数据到表分区后，需要重建索引分区

    重建索引以启用键压缩

    位图索引本质不同于B树索引，建议重建

二、术语

1、高基数：简单理解就是表中列的不同值多。

2、低基数：建单理解就是表中的列的不同值少。

3、以删除的叶节点数量：指得是数据行的delete操作从逻辑上删除的索引节点 的数量，要记住oracle在删除数据行后，将 " 死 " 节点保留在索引中，这样做可以加快sql删除操作的速度，因此oracle删除数据行后可以不必重新平衡索引。

4、索引高度：索引高度是指由于数据行的插入操作而产生的索引层数，当表中添加大量数据时，oracle将生成索引的新层次以适应加入的数据行，因此，oracle索引可能有4层，但是这只会出现在索引数中产生大量插入操作的区域。Oracle索引的三层结构可以支持数百万的项目，而具备4层或是更多层的需要重建。

5、每次索引访问的读取数：是指利用索引读取一数据行时所需要的逻辑I/O操作数，逻辑读取不必是物理读取，因为索引的许多内容已经保存在数据缓冲区，然而，任何数据大于10的索引都需要重建。

三、什么时候重建呢？

察看 dba_indexes 中的 blevel 。这列是说明索引从根块到叶快的级别，或是深度。如果级别大于等于4。则需要重建，

如下 ：Select index_name,blevel from dba_indexes where blevel>=4.

另一个从重建中受益的指标显然是当该索引中的被删除项占总的项数的百分比。如果在20%以上时，也应当重建，如下

SQL>analyze index index_name validate structure

SQL>select (del_lf_rows_len/lf_rows_len)*100 from index_stats where name=' index_name '

就能看到是否这个索引被删除的百分比。

四、重建索引的方法

1、删除并从头开始建索引：方法是最慢的，最耗时的。一般不建议。

2、使用 alter index index_name rebuild 命令重建索引。

3、alter index indexname rebuild online;

4、使用 alter index index_name coalesce 命令重建索引。

五、什么样的重建方式更好？

1、删除并从头开始建索引：方法是最慢的，最耗时的。一般不建议。

2、Alter index index_name rebuild

快速重建索引的一种有效的办法，因为使用现有索引项来重建新索引，如果客户操作时有其他用户在对这个表操作，尽量使用带online参数来最大限度的减少索引重建时将会出现的任何加锁问题，alter index index_name rebuild online。

但是,由于新旧索引在建立时同时存在，因此，使用这种技巧则需要有额外的磁盘空间可临时使用，当索引建完后把老索引删除，如果没有成功，也不会影响原来的索引。利用这种办法可以用来将一个索引移到新的表空间。

Alter index index_name rebuild tablespace tablespace_name 。

这个命令的执行步骤如下：

首先，逐一读取现有索引，以获取索引的关键字。

其次，按新的结构填写临时数据段。

最后，一旦操作成功，删除原有索引树，将临时数据段重命名为新的索引。

需要注意的是alter index index_name rebuild 命令中必须使用tablespace字句，以保证重建工作是在现有索引相同的表空间进行。

3、alter index index_name coalesce

使用带有coalesce参数时重建期间不需要额外空间，它只是在重建索引时将处于同一个索引分支内的叶块拼合起来，这最大限度的减少了与查询过程中相关的潜在的加锁问题，但是，coalesce选项不能用来将一个索引转移到其他表空间。

六、重建分区表上的分区索引

重建分区索引方法：

Alter index indexname rebuild partition paritionname tablespace tablespacename;

Alter index indexname rebuild subpartition partitioname tablespace tablespacename;

Partition name 可以从user_ind_partitions查找

Tablepace 参数允许alter index操作更改索引的存储空间。