索引Index Rebuild和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

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

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

|? 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

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

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

|? 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基于是数据表的内容，检索时间略长，但是引起的锁定动作也相对较小。

下面，笔者从实践跟踪角度，

索引Index Rebuild和Rebuild Online 详述(一)