關於Oracle索引樹的結構以及它們對Oracle性能調優是否重要存在大量的
激烈的爭論
而且已經有很多文章試圖來描述這些重要的Oracle性能工具的內部工作機制
關於這個論題也出現了一些新書
例如由
國際Oracle用戶組
（IOUG）主席Kim Floss所著的《Oracle索引管理秘訣》和《Oracle SQL 性能調優和
基於代價的優化器
內幕》
正如我們知道的Oracle提供了大量索引結構每種索引結構都有其好處和不足
* B樹索引從最早的Oracle發行版本開始Oracle就一直使用的標准樹索引就是B樹索引
* 位圖索引當某個索引列含有很少數量的不同的值（即低基數）時使用位圖索引這對於那些只讀數據庫而言速度超快但對需要經常性更新的系統不適合
* 位圖連接索引這是針對來自其他表的數據列出現在某個連接表的多列索引時使用的索引下面是在from子句和where子句中使用類似SQL的創建索引的惟一語法
create bitmap index
part_suppliers_state
on
inventory( partspart_type supplierstate )
from
inventory i
parts p
supplier s
where
ipart_id=ppart_id
and
isupplier_id=psupplier_id;
盡管有關索引重建的爭論仍在激烈進行著但還是存在每個人都認可的索引管理的某些領域在內部機制上一個Oracle B樹索引的結構和一個UNIX I結點的結構非常相似索引中的每個數據塊都是索引樹中的一個結點位於最底部的結點（葉數據塊）包含一對符號鍵和行ID值
Oracle b樹索引
為了正確管理這些數據塊Oracle控制著每個數據塊中指針的分配隨著一棵Oracle樹的增長（通過往表裡插入新行）Oracle會填充這個數據塊當這個數據塊滿時Oracle會分裂它創建新的索引結點（數據塊）來管理索引內的符號鍵
因此一個Oracle索引塊可能包含以下兩種類型的指針
* 指向其他索引結點（數據塊）的指針
* 指向數據庫表中特定行的行ID指針
Oracle管理著索引塊內指針的分配這就是為什麼我們不能為索引指定一個PCTUSED值（自由列表重鏈接門檻）的原因當我們檢查一個索引塊的結構時我們發現每個索引結點內部條目的數量是下面兩個值的一個函數
． 符號鍵的長度
． 索引表空間的塊尺寸
由於塊尺寸影響每個索引結點內部的符號鍵的數量可以推理出塊尺寸對一棵索引樹的結構也會有影響在其他條件相同的情況下采用K的大數據塊能容納更多的符號鍵從而能夠比在K表空間中創建的相同的索引更加平整采用大的數據塊也將減少索引訪問期間一致獲取的數量從而提高分散讀訪問的性能
索引中的每個數據塊包含索引樹中的結點位於最底部的結點（葉數據塊）包含一對符號鍵和行ID值隨著一棵Oracle樹的增長（通過往表裡插入新行）Oracle會填充這個數據塊當這個數據塊滿時Oracle會分裂它創建新的索引結點（數據塊）來管理索引內的符號鍵因此一個Oracle索引塊可能包含指向其他索引結點或行ID/符號鍵對的指針
索引行為和Oracle塊尺寸
由於塊尺寸影響每個索引結點內部的符號鍵的數量可以推理出塊尺寸對一棵索引樹的結構也會有影響在其他條件相同的情況下采用K的大數據塊能容納更多的符號鍵從而能夠比在K表空間中創建的相同的索引更加平整
今天大多數Oracle性能調優專家都利用Oracle提供的多種塊尺寸的特色因為它提供了緩沖區隔離和以最合適塊尺寸來存放對象從而減少緩沖區浪費的能力一些Oracle基准測試的世界記錄都使用很大的數據緩沖區和多種塊尺寸
根據《Oracle數據庫管理員認證Oracle 認證數據庫管理專家教師指南》一書的作者Christopher Foot的一篇文章更大的塊尺寸在某些情況下非常有幫助
更大的塊尺寸意味著在B樹索引的分支結點中有更多的空間來存儲符號鍵從而可以降低樹的高度和提高索引查詢的性能
在任何情況下似乎有證據表明塊尺寸影響樹的結構這為數據塊影響樹的結構提供了有力支持
你可以使用大數據塊（）緩沖區來存儲來自作為重復性大規模掃描對象的索引或表中的數據這真的會提高性能麼？一個小的但透漏內情的測試能回答這個問題
在這個測試中將對某個使用K數據塊尺寸的Oracle i數據庫執行以下查詢這個數據庫同時也使用K緩沖區和K大小的表空間
select
count(*)
from
eradminadmission
where
patient_id between and ;
表eradminadmission含有行數據並在patient_id列上建立了一個索引對上面的查詢語句執行EXPLAIN命令揭示出它使用索引范圍掃描來產生想要的目的結果
Execution Plan
SELECT STATEMENT Optimizer=CHOOSE
(Cost= Card= Bytes=)
SORT (AGGREGATE)
INDEX (FAST FULL SCAN) OF ADMISSION_PATIENT_ID
(NONUNIQUE) (Cost= Card= Bytes=)
使用位於一個標准K表空間的索引來執行這個查詢（兩次以消除分析活動並緩沖任何數據）產生了以下實時統計信息
Statistics
recursive calls
db block gets
consistent gets
physical reads
redo size
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
為了測試新的K緩沖區和K表空間的效果將使用K的表空間來重建這個查詢所用的索引K的表空間和原來的K的表空間相比除了更大的塊尺寸其他特性一模一樣
alter index
eradminadmission_patient_id
rebuild nologging noreverse tablespace indx_k;
一旦在K表空間中建立好這個索引就再次執行這個查詢（同樣也是執行兩次）會產生以下的運行時統計信息
Statistics
recursive calls
db block gets
consistent gets
physical reads
redo size
bytes sent via SQL*Net to client
bytes received via SQL*Net from client
SQL*Net roundtrips to/from client
sorts (memory)
sorts (disk)
rows processed
正如你所看到的邏輯讀操作的次數被減少了一半僅僅是由於使用了新的K表空間和K數據緩沖區很顯然正確使用新的數據緩沖區和Oraclei及其以上版本的多種塊尺寸表空間的特色很值得在你的數據庫中被試驗和研究
定期進行索引重建？
爭論的另外一個領域是是否存在一些確定的規則可以用來確定何時能夠從索引重建中獲取性能提高許多使用Oracle的企業都定期進行索引重建並聲稱在他們和重建他們的Oracle B樹索引後獲得了相當大的速度提升
在Oracle世界上展示了Sushil Kumar所著的一篇題為Oracle數據庫g自我管理的數據庫的文章Kumar聲明說Oracleg的自動維護任務（AMT）特色將自動檢測並重建潛在的最優化的索引
自動工作負載信息庫（AWR）給oracleg提供了關於數據庫各種使用情況的詳細信息通過分析存儲在自動工作負載信息庫（AWR）中的信息g數據庫可以決定是否需要執行數據庫性能維護任務比如優化器統計數字的刷新重建索引等等 以自動維護任務AMT為基礎oracle數據庫可以自動執行這些操作
盡管如此仍有不少反對定期重建索引的論點一些oracle內部的專家堅持認為oracle索引在空間重用和訪問速度上是非常高效的b－樹索引在極少情況下才需要被重建他們堅持認為邏輯輸入輸出的減少應該是可測量的並且如果重建索引是有好處的某些人應該已經提出了可以證明的規則
結論
多種數據塊尺寸的特色能夠提高Oracle索引的性能而且在某些情況下重建索引可以提高查詢速度這是顯而易見的人們期望新的Oracleg自動維護任務AMT允許自動檢測並重建潛在的最優化索引結構
如果你喜歡Oracle性能調優技巧你或許會喜歡Rampant科技出版社出版的我的最新著作創建具有自我調優功能的Oracle數據庫它僅售美元（我認為收取書費是不對的！）
From:http://tw.wingwit.com/Article/program/Oracle/201311/18589.html
