聊聊索引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過程中資料讀取的差異性。