Oracle ~ 重建索引(包括分区)
尽量不要重建索引
a. 大多数脚本都依赖 index_stats 动态表。此表使用以下命令填充:
analyze index … validate structure;
尽管这是一种有效的索引检查方法,但是它在分析索引时会获取独占表锁。对于大型索引,其影响会是巨大的,因为在此期间不允许对表执行DML 操作。
虽然该方法可以在不锁表的情况下在线运行,但是可能要消耗额外的时间。
b. 重建索引的直接结果是 REDO 活动可能会增加,总体系统负载也可能会提高。
插入/更新/删除操作会导致索引随着索引的分割和增长不断发展。
重建索引后,它将连接的更为紧凑;但是,随着对表不断执行 DML 操作,必须再次分割索引,直到索引达到平衡为止。
结果,重做活动增加,且索引分割更有可能对性能产生直接影响,因为我们需要将更多的 I/O、CPU 等用于索引重建。
经过一段时间后,索引可能会再次遇到“问题”,因此可能会再被标记为重建,从而陷入恶性循环。
因此,通常最好是让索引处于自然平衡和(或)至少要防止定期重建索引。
因此,一般情况下极少会重建索引, 通常是优先考虑index coalesce(索引合并),而不是重建索引。索引合并有如下优点:
a、不需要占用盘存储空间 2 倍的空间
b、可以在线操作
c、无需重建索引结构,而是尽快地合并索引叶块,这样可避免系统开销过大。
真正需要重建索引的情形
- 索引或索引分区因介质故障损坏
- 标记为UNUSABEL的索引需要重建
- 索引移动到新的表空间或需要改变某些存储参数
- 通过SQL*Loader加载数据到表分区后,需要重建索引分区
- 重建索引以启用键压缩
- 位图索引本质不同于B树索引,建议重建
如何重建索引
查询是否需要重建索引: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 的场合 , 该索引考虑重建
1、drop 原来的索引,然后再创建索引
删除索引:drop index IX_PM_USERGROUP;
创建索引:create index IX_PM_USERGROUP on T_PM_USER (fgroupid);
说明:此方式耗时间,无法在24*7环境中实现,不建议使用。
2 、直接重建
alter index indexname rebuild;
或 alter index indexname rebuild online;
说明:此方式比较快,可以在24*7环境中实现,建议使用此方式
2.1 alter index rebuild 和alter index rebuil online的区别
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;