欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  数据库

索引Index Rebuild和Rebuild Online 详述

程序员文章站 2022-06-12 18:11:54
...

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

    更多详情见请继续阅读下一页的精彩内容: