索引組織表（Index Organizied Table）

索引組織表的詳細引數

ops$tkyte@ORA10GR1> select dbms_metadata.get_ddl( 'TABLE', 'T1' ) from dual;

S_METADATA.GET_DDL('TABLE','T1')

-----------------------------------------------------------------------------

CREATE TABLE "OPS$TKYTE"."T1"

"X" NUMBER(*,0),

"Y" VARCHAR2(25),

"Z" DATE,

PRIMARY KEY ("X") ENABLE

ANIZATION INDEX

OMPRESS

PCTFREE 10 INITRANS 2 MAXTRANS 255 LOGGING

STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)

TABLESPACE "USERS"

PCTTHRESHOLD 50

NOCOMPRESS 選項

這個選項對索引一般都可用。它告訴 Oracle 把每個值分別儲存在各個索引條目中（也就是不壓縮）。如果物件的主鍵在 A、B 和 C 列上， A、B 和 C 的每一次出現都會物理地儲存。 NOCOMPRESS 反過來就是 COMPRESS N ，在此 N 是一個整數，表示要壓縮的列數。這樣可以避免重複值，並在塊級提取 “公因子”（ factor out ）。這樣在 A 的值（以及 B 的值）重複出現時，將不再物理地儲存它們。

下面做一個快速的測試，對前面 CREATE TABLE 的 SELECT 分別採用 NOCOMPRESS 、 COMPRESS 1 和COMPRESS 2 選項，來展示能節省多少空間。先來建立 IOT ，但不進行壓縮：

ops$tkyte@ORA10GR1> create table iot

2 ( owner, object_type, object_name,

3 constraint iot_pk primary key(owner,object_type,object_name)

4 )

5 organization index

6 NOCOMPRESS

7 as

8 select distinct owner, object_type, object_name

9 from all_objects

10 /

tablle created.

現在可以測量所用的空間。為此我們將使用 ANALYZE INDEX VALIDATE STRUCTURE 命令。這個命令會填寫一個名為 INDEX_STATS 的動態效能檢視，其中最多隻包含一行，即這個 ANALYZE 命令最後一次執行的資訊：

ops$tkyte@ORA10GR1> analyze index iot_pk validate structure;

index analyzed.

ops$tkyte@ORA10GR1> select lf_blks, br_blks, used_space,

2 opt_cmpr_count, opt_cmpr_pctsave

3 from index_stats;

LF_BLKS  BR_BLKS  USED_SPACE  OPT_CMPR_COUNT  OPT_CMPR_PCTSAVE

284  3  2037248 2 33

由此顯示出，我們的索引目前使用了 284 個葉子塊（即資料所在的塊），並使用了 3 個分支塊（ Oracle在索引結構中導航所用的塊）來找到這些葉子塊。使用的空間大約是 2MB （2,038,248 位元組）。另外兩列名字有些奇怪，這兩列是要告訴我們一些資訊。 OPT_CMPR_COUNT （最優壓縮數）列要說的是：“ 如果你把這個索引置為 COMPRESS 2 ，就會得到最佳的壓縮 ” 。 OPT_CMPR_PCTSAVE （最優的節省壓縮百分比）則是說 ，如果執行 COMPRESS 2 ，就能節省大約 1/3 的儲存空間，索引只會使用現在 2 /3 的磁碟空間。

OVERFLOW&PCTTHRESHOLD&INCLUDING選項

OVERFLOW 子句允許你建立另一個段（這就使得 IOT 成為一個多段物件，就像有一個 CLOB 列一樣），如果 IOT 的行資料變得太大，就可以溢位到這個段中。

注意：構成主鍵的列不能溢位，它們必須直接放在葉子塊上。

PCTTHRESHOLD ：行中的資料量超過塊的這個百分比時，行中餘下的列將儲存在溢位段中。所以，如果 PCTTHRESHOLD 是 10% ，而塊大小是 8KB ，長度大於 800 位元組的行就會把其中一部分儲存在別處，而不能在索引塊上儲存。

INCLUDING ：行中從第一列直到 INCLUDING 子句所指定列（也包括這一列）的所有列都儲存在索引塊上，餘下的列儲存在溢位段中。

對於 IOT 最後要考慮的是建立索引。 IOT 本身可以有一個索引，就像在索引之上再加索引，這稱為二次索引（ secondary index ）。 正常情況下，索引包含了所指向的行的實體地址，即 rowid 。而 IOT 二次索引無法做到這一點；它必須使用另外某種方法來指示行的地址。這是因為 IOT 中 的行可以大量移動， 而且它不像堆組織表中的行那樣 “ 遷移 ” 。 IOT 中的行肯定在索引結構中的每個位置上，這取決於它的主鍵值；只有當索引本身的大小和形狀 發生改變時行才會移動。

    為了適應這種情況， Oracle 引入了一個邏輯 rowid （ logical rowid ）。 這些邏輯 rowid 根據 IOT 主鍵建立。對於行的當前位置還可以包含一個 “ 猜測 ” ，不過這個猜測幾乎是錯的，因為稍過一段時間後， IOT中的資料可能就會 移動。這個猜測是行第一次置於二次索引結構中時在 IOT 中的實體地址。如果 IOT 中 的行必須移動到另外一個塊上，二次索引中的猜測就會變得 “ 過時 ” 。因 此，與常規表相比， IOT 上的索 引效率稍低。在一個常規表上，索引訪問通常需要完成一個 I/O 來掃描索引結構，然後需要一個讀來讀取表資料。對於 IOT ， 通常要 完成兩個掃描；一次掃描二次結構，另一次掃描 IOT 本身。除此之外， IOT 上的索引可以使用非主鍵列提供 IOT 資料的快速、高效訪問。