聊聊索引Index Rebuild和Rebuild Online（上）

转载至：http://blog.itpub.net/17203031/viewspace-1471924/

 

在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过程当中数据读取的差别性。