在oracle运维领域，两个围绕索引的概念一直在网络上被讨论，一个是index定期重构的必要性，另一个对rebuild和rebuild online的讨
在oracle运维领域，两个围绕索引的概念一直在网络上被讨论，一个是index定期重构的必要性，另一个对rebuild和rebuild online的讨论。前者很多前辈在各种场合，包括oracle mos，都有了比较深刻的讨论。
对后者的讨论主要是集中两个方面，即：
对于大数据、高可用性的系统，索引rebuild动作一定要慎用，最好选择在dml操作比较少的时间窗进行，避免影响业务系统；rebuild online和rebuild在处理上的差异。相对于rebuild，rebuild online对于dml操作的锁定动作是比较小的，但是相应操作时间也比较多。如果是高可用7*24系统，rebuild online往往是比较容易接受的一种折中策略；本篇主要从执行计划和跟踪执行两个角度，分析两种rebuild索引的特点。
1、环境介绍
笔者选择oracle 11gr2进行测试，具体版本为11.2.0.4。
sql> select * from v$version;
banner
--------------------------------------------------------------------------------
oracle database 11g enterprise edition release 11.2.0.4.0 - production
pl/sql release 11.2.0.4.0 - production
core 11.2.0.4.0 production
tns for linux: version 11.2.0.4.0 - production
nlsrtl version 11.2.0.4.0 - production
首先创建数据表t。
sql> create table t as select * from dba_objects;
table created
sql> create index idx_t_id on t(object_id);
index created
sql> exec dbms_stats.gather_table_stats(user,'t',cascade => true);
pl/sql procedure successfully completed
下面我们先从执行计划层面进行分析研究。
2、explain plan研究执行计划
explain plan是我们经常使用分析sql语句执行计划的方法。笔者发现对于alert index这类ddl操作，explain语句依然可以分析出对应的结果。
首先测试rebuild语句。
sql> explain plan for alter index idx_t_id rebuild;
explained
sql> select * from table(dbms_xplan.display);
plan_table_output
--------------------------------------------------------------------------------
plan hash value: 1483129259
--------------------------------------------------------------------------------
| id | operation | name | rows | bytes | cost (%cpu)| time
--------------------------------------------------------------------------------
| 0 | alter index statement | | 86129 | 420k| 336 (1)| 00:00:0
| 1 | index build non unique| idx_t_id | | | |
| 2 | sort create index | | 86129 | 420k| |
| 3 | index fast full scan| idx_t_id | | | |
--------------------------------------------------------------------------------
10 rows selected
这其中，我们首先看到了index fast full scan动作。在笔者之前的文章中，曾经比较详细的分析过index fast full scan和index full scan的区别。简单说两者差异如下：
ü index fast full scan是标准的多快读操作；index full scan是单块读操作；
ü index fast full scan返回结果是无序结果；index full scan返回有序结果集合；
ü index fast full scan能进行并行操作；index full scan只能支持单进程读动作；
在上面的执行计划中，我们发现rebuild操作没有以数据表为基础，而是以索引idx_t_id的数据（当然是叶子节点）作为创建依据。由于index fast full scan返回的无序结果集合，之后就调用了sort create index动作形成新的索引对象。
综合来看，对于rebuild动作而言，在读取索引的过程中，以索引的叶子节点数据作为数据依据。更进一步说，如果rebuild的索引和数据表已经存在不一致的情况，，那么新生成的索引也一定是不一致的。
下面我们看rebuild online的分析：
sql> explain plan for alter index idx_t_id rebuild online;
explained
sql> select * from table(dbms_xplan.display);
plan_table_output
--------------------------------------------------------------------------------
plan hash value: 1193657316
--------------------------------------------------------------------------------
| id | operation | name | rows | bytes | cost (%cpu)| time
--------------------------------------------------------------------------------
| 0 | alter index statement | | 86129 | 420k| 336 (1)| 00:00:0
| 1 | index build non unique| idx_t_id | | | |
| 2 | sort create index | | 86129 | 420k| |
| 3 | table access full | t | 86129 | 420k| 336 (1)| 00:00:0
--------------------------------------------------------------------------------
10 rows selected
从执行计划看，两者的差异主要在第三步，就是table access full操作，而且是基于数据表t的操作。所以说明：rebuild online是基于对原始数据表的数据收集，而且是针对数据表进行的全表扫描操作。
这也就部分解释了为什么rebuild online会比rebuild时间长一些，因为table access full操作会访问所有的数据段结构，而index fast full scan会访问所有的索引段结构。一般而言，索引段是远远小于数据段的。
综合来看，rebuild online基于是数据表的内容，检索时间略长，但是引起的锁定动作也相对较小。
下面，笔者从实践跟踪角度，分析一下rebuild和rebuild online过程中数据读取的差异性。
更多详情见请继续阅读下一页的精彩内容：