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

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

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

因此，一般情况下极少会重建索引， 通常是优先考虑index coalesce（索引合并），而不是重建索引。索引合并有如下优点： a、不需要占用盘存储空间 2 倍的空间 b、可以在线操作 c、无需重建索引结构，而是尽快地合并索引叶块，这样可避免系统开销过大。

查询是否需要重建索引：Analyze index index_name validate structure; 查询是否需要重建索引：select height,DEL_LF_ROWS/LF_ROWS from index_stats; 当查询出来的 height>=4 或者 DEL_LF_ROWS/LF_ROWS>0.2 的场合 ， 该索引考虑重建

删除索引：drop index IX_PM_USERGROUP;

创建索引：create index IX_PM_USERGROUP on T_PM_USER (fgroupid);

说明：此方式耗时间，无法在24*7环境中实现，不建议使用。

alter index indexname rebuild; 或 alter index indexname rebuild online;

说明：此方式比较快，可以在24*7环境中实现，建议使用此方式

1、扫描方式不同

Rebuild以index fast full scan（or table full scan） 方式读取原索引中的数据来构建一个新的索引，有排序的操作;

rebuild online 执行表扫描获取数据，有排序的操作;

说明：Rebuild 方式 (index fast full scan or table full scan 取决于统计信息的cost)

2 、rebuild 会阻塞 dml 操作 ，rebuild online 不会阻塞 dml 操作

3 、rebuild online 时系统会产生一个 SYS_JOURNAL_xxx 的 IOT 类型的系统临时日志表 ， 所有 rebuild online 时索引的变化都记录在这个表中 ， 当新的索引创建完成后 ， 把这个表的记录维护到新的索引中去 ， 然后 drop 掉旧的索引 ，rebuild online 就完成了

1、 执行rebuild操作时，需要检查表空间是否足够

2、虽然说rebuild online操作允许dml操作，但是还是建议在业务不繁忙时间段进行

Rebuild操作会产生大量redo log

重建分区索引方法：

分区：Alter index indexname rebuild partition paritionname tablespace tablespacename;

子分区：Alter index indexname rebuild subpartition partitioname tablespace tablespacename;