導讀：關于Oracle數(shù)據(jù)庫中索引樹的結構以及它們對Oracle性能調(diào)優(yōu)是否重要存在大量的、激烈的爭論，而且已經(jīng)有很多文章試圖來描述這些重要的Oracle性能工具的內(nèi)部工作機制。

正如我們知道的，Oracle提供了大量索引結構，每種索引結構都有其好處和不足：

1. 　　 B樹索引。從最早的Oracle發(fā)行版本開始，Oracle就一直使用的標準樹索引就是B樹索引。
2. 　　位圖索引。當某個索引列含有很少數(shù)量的不同的值(即低基數(shù))時，使用位圖索引。這對于那些只讀數(shù)據(jù)庫而言速度超快，但對需要經(jīng)常性更新的系統(tǒng)不適合。
3. 　　 位圖連接索引。這是針對來自其他表的數(shù)據(jù)列出現(xiàn)在某個連接表的多列索引時使用的索引。下面是在from子句和where子句中使用類似SQL的創(chuàng)建索引的惟一語法。

以下是代碼片段：

　create bitmap index   
　　part_suppliers_state   
　　on   
　　inventory( parts.part_type, supplier.state )   
　　from   
　　inventory i,   
　　parts p,   
　　supplier s   
　　where   
　　i.part_id=p.part_id   
　　and   
　　i.supplier_id=p.supplier_id;   

　　盡管有關索引重建的爭論仍在激烈進行著，但還是存在每個人都認可的索引管理的某些領域。在內(nèi)部機制上，一個Oracle B-樹索引的結構和一個UNIX I-結點的結構非常相似。索引中的每個數(shù)據(jù)塊都是索引樹中的一個結點，位于***部的結點(葉數(shù)據(jù)塊)包含一對符號鍵和行ID值。

　　Oracle b-樹索引

　　為了正確管理這些數(shù)據(jù)塊，Oracle控制著每個數(shù)據(jù)塊中指針的分配。隨著一棵Oracle樹的增長(通過往表里插入新行)，Oracle會填充這個數(shù)據(jù)塊，當這個數(shù)據(jù)塊滿時Oracle會分裂它，創(chuàng)建新的索引結點(數(shù)據(jù)塊)來管理索引內(nèi)的符號鍵。

因此，一個Oracle索引塊可能包含以下兩種類型的指針：

1. 　　 指向其他索引結點(數(shù)據(jù)塊)的指針
2. 　　 指向數(shù)據(jù)庫表中特定行的行ID指針

　　Oracle管理著索引塊內(nèi)指針的分配，這就是為什么我們不能為索引指定一個PCTUSED值(自由列表重鏈接門檻)的原因。當我們檢查一個索引塊的結構時，我們發(fā)現(xiàn)每個索引結點內(nèi)部條目的數(shù)量是下面兩個值的一個函數(shù)：

　　1. 符號鍵的長度

　　2. 索引表空間的塊尺寸

　　由于塊尺寸影響每個索引結點內(nèi)部的符號鍵的數(shù)量，可以推理出：塊尺寸對一棵索引樹的結構也會有影響。在其他條件相同的情況下，采用32K的大數(shù)據(jù)塊能容納更多的符號鍵，從而能夠比在2K表空間中創(chuàng)建的相同的索引更加平整。采用大的數(shù)據(jù)塊也將減少索引訪問期間一致獲取的數(shù)量，從而提高分散讀訪問的性能。

　　索引中的每個數(shù)據(jù)塊包含索引樹中的“結點”，位于***部的結點(葉數(shù)據(jù)塊)包含一對符號鍵和行ID值。隨著一棵Oracle樹的增長(通過往表里插入新行)，Oracle會填充這個數(shù)據(jù)塊，當這個數(shù)據(jù)塊滿時Oracle會分裂它，創(chuàng)建新的索引結點(數(shù)據(jù)塊)來管理索引內(nèi)的符號鍵。因此，一個Oracle索引塊可能包含指向其他索引結點或行ID/符號鍵對的指針。

索引行為和Oracle塊尺寸

　　由于塊尺寸影響每個索引結點內(nèi)部的符號鍵的數(shù)量，可以推理出：塊尺寸對一棵索引樹的結構也會有影響。在其他條件相同的情況下，采用32K的大數(shù)據(jù)塊能容納更多的符號鍵，從而能夠比在2K表空間中創(chuàng)建的相同的索引更加平整。

　　今天，大多數(shù)Oracle性能調(diào)優(yōu)專家都利用Oracle提供的多種塊尺寸的特色，因為它提供了緩沖區(qū)隔離和以最合適塊尺寸來存放對象從而減少緩沖區(qū)浪費的能力。一些Oracle基準測試的世界記錄都使用很大的數(shù)據(jù)緩沖區(qū)和多種塊尺寸。

　　根據(jù)《Oracle數(shù)據(jù)庫管理員認證：“Oracle 認證數(shù)據(jù)庫管理專家”教師指南》一書的作者Christopher Foot的一篇文章，更大的塊尺寸在某些情況下非常有幫助：

　　“更大的塊尺寸意味著在B-樹索引的分支結點中有更多的空間來存儲符號鍵，從而可以降低樹的高度和提高索引查詢的性能。”

　　在任何情況下，似乎有證據(jù)表明塊尺寸影響樹的結構，這為數(shù)據(jù)塊影響樹的結構提供了有力支持。

　　你可以使用大數(shù)據(jù)塊(16-32)緩沖區(qū)來存儲來自作為重復性大規(guī)模掃描對象的索引或表中的數(shù)據(jù)。這真的會提高性能么？一個小的但透漏內(nèi)情的測試能回答這個問題。

#p#

　　在這個測試中，將對某個使用8K數(shù)據(jù)塊尺寸的Oracle 9i數(shù)據(jù)庫執(zhí)行以下查詢，這個數(shù)據(jù)庫同時也使用16K緩沖區(qū)和16K大小的表空間。

以下是代碼片段：
　

　select   
　　count(*)   
　　from   
　　eradmin.admission   
　　where   
　　patient_id between 1 and 40000; 

以下是代碼片段：

　Execution Plan   
　　SELECT STATEMENT Optimizer=CHOOSE   
　　(Cost=41 Card=1 Bytes=4)   
　　1 0 SORT (AGGREGATE)   
　　2 1 INDEX (FAST FULL SCAN) OF 'ADMISSION_PATIENT_ID'   
　　(NON-UNIQUE) (Cost=41 Card=120002 Bytes=480008)   

以下是代碼片段：
　

　Statistics   
　　0 recursive calls   
　　0 db block gets   
　　421 consistent gets   
　　0 physical reads   
　　0 redo size   
　　371 bytes sent via SQL*Net to client   
　　430 bytes received via SQL*Net from client   
　　2 SQL*Net roundtrips to/from client   
　　0 sorts (memory)   
　　0 sorts (disk)   
　　1 rows processed   

　　為了測試新的16K緩沖區(qū)和16K表空間的效果，將使用16K的表空間來重建這個查詢所用的索引，16K的表空間和原來的8K的表空間相比，除了更大的塊尺寸其他特性一模一樣。

以下是代碼片段：

　alter index   
　　eradmin.admission_patient_id   
　　rebuild nologging noreverse tablespace indx_16k;   

　　一旦在16K表空間中建立好這個索引，就再次執(zhí)行這個查詢(同樣也是執(zhí)行兩次)，會產(chǎn)生以下的運行時統(tǒng)計信息：

以下是代碼片段：

　Statistics   
　　0 recursive calls   
　　0 db block gets   
　　211 consistent gets   
　　0 physical reads   
　　0 redo size   
　　371 bytes sent via SQL*Net to client   
　　430 bytes received via SQL*Net from client   
　　2 SQL*Net roundtrips to/from client   
　　0 sorts (memory)   
　　0 sorts (disk)   
　　1 rows processed   

　　正如你所看到的，邏輯讀操作的次數(shù)被減少了一半，僅僅是由于使用了新的16K表空間和16K數(shù)據(jù)緩沖區(qū)。很顯然，正確使用新的數(shù)據(jù)緩沖區(qū)和Oracle9i及其以上版本的多種塊尺寸表空間的特色，很值得在你的數(shù)據(jù)庫中被試驗和研究。

定期進行索引重建？

　　爭論的另外一個領域是：是否存在一些確定的規(guī)則可以用來確定何時能夠從索引重建中獲取性能提高。許多使用Oracle的企業(yè)都定期進行索引重建，并聲稱在他們和重建他們的Oracle B-樹索引后獲得了相當大的速度提升。

　　在“Oracle世界2003”上，展示了Sushil Kumar所著的一篇題為“Oracle數(shù)據(jù)庫10g：自我管理的數(shù)據(jù)庫”的文章，Kumar聲明說Oracle10g的“自動維護任務”(AMT)特色將自動檢測并重建潛在的***化的索引。

　　“自動工作負載信息庫(AWR)給oracle10g提供了關于數(shù)據(jù)庫各種使用情況的詳細信息。通過分析存儲在自動工作負載信息庫(AWR)中的信息，10g數(shù)據(jù)庫可以決定是否需要執(zhí)行數(shù)據(jù)庫性能維護任務，比如優(yōu)化器統(tǒng)計數(shù)字的刷新、重建索引等等。 以“自動維護任務”AMT為基礎，oracle數(shù)據(jù)庫可以自動執(zhí)行這些操作。”

　　盡管如此，仍有不少反對定期重建索引的論點。一些oracle內(nèi)部的專家堅持認為oracle索引在空間重用和訪問速度上是非常高效的，b-樹索引在極少情況下才需要被重建。他們堅持認為邏輯輸入輸出的減少應該是可測量的，并且如果重建索引是有好處的，某些人應該已經(jīng)提出了可以證明的規(guī)則。

結論

　　多種數(shù)據(jù)塊尺寸的特色能夠提高Oracle索引的性能，而且在某些情況下重建索引可以提高查詢速度，這是顯而易見的。人們期望新的Oracle10g“自動維護任務”AMT允許自動檢測并重建潛在的***化索引結構。希望上文中涉及到的內(nèi)容對大家能夠有所幫助。

【編輯推薦】

1. Oracle數(shù)據(jù)庫關閉方法總結
2. Oracle數(shù)據(jù)庫效率技巧：避免錯誤的索引
3. ORACLE實例和ORACLE數(shù)據(jù)庫詳解
4. Oracle數(shù)據(jù)庫基本常識