聊聊索引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過程當中數據讀取的差別性。