聊聊索引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过程被数读取的差异性。

 

 

 

相关文章