【ACCESS】聊聊索引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。

 

ACCESS, 

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(Fast) Full
Scan动作。在作者此前的著作中,曾经相比详细的剖析过Index 法斯特 Full
Scan和Index Full Scan的分别。简单说两者反差如下:

ü  Index Fast(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(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过程中数量读取的差别性。

 

 

 

相关文章