轉載至：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過程中數據讀取的差異性。