5 索引组织表(IOT Index-Organized Table)的键压缩
在创建IOT表时，有一个存储选项NOCOMPRESS，这个选项的意思是不压缩，即对IOT表的索引条目不压缩。该选项不单对IOT表有效，同样对B-Tree索引也适用。
与NOCOMPRESS选项对应的就是COMPRESS N，这个N只能取值整数，表示要压缩的列数，在数据块儿级别提取"公因子"，用以避免存储重复值。如IOT表的主键是(col1,col2,col3)的联合主键的话，那么COMPRESS 2就可以表示，如果在表中重复出现多个col1,col2的重复值的话，那么Oracle就只存储col1,col2 1次，对于重复的记录不再存储。所以，达到压缩的目的。
接下来，看一个示例：
1 创建一个NOCOMPRESS的IOT表：
[oracle@oracle11g ~]$ sqlplus
SQL*Plus: Release 11.2.0.1.0 Production on Fri Nov 23 14:21:43 2012
Copyright (c) 1982, 2009, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning and Automatic Storage Management options
SQL> conn hr/hr
Connected.
SQL> 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;
Table created.
SQL> select count(*) from iot;
COUNT(*)
----------
55646
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
no rows selected
SQL>
看到表里有55646条记录。
2 用ANALYZE INDEX VALID STRUCTURE来分析这个IOT表的主键：
SQL> analyze index iot_pk validate structure;
Index analyzed.
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
347 3 2493786 2 33
SQL>
看到这个IOT表的索引使用了347个叶子块，3个分枝块，占用空间大小是2493786字节，约2.4M。
3 使用COMPRESS 1选项来重建IOT表：
SQL> alter table iot move compress 1;
Table altered.
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
no rows selected
SQL> analyze index iot_pk validate structure;
Index analyzed.
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
304 3 2178229 2 23
SQL>
然后，看到这个IOT表的索引现在使用了304个叶子块，3个分枝块，占用空间大小是2178229字节，约2.1M。
4 使用COMPRESS 2继续压缩这个IOT表：
SQL> alter table iot move compress 2;
Table altered.
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
no rows selected
SQL> analyze index iot_pk validate structure;
Index analyzed.
SQL> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
233 1 1670153 2 0
SQL>
最终，看到这个IOT表的索引现在使用了233个叶子块，1个分枝块，占用空间大小是1670153字节，约1.6M。
说明：
从上可以看出，使用不同的压缩级别，索引的占用的空间大小逐渐变小，从最初的2.4M变成1.6M。叶子块从最初的347变成233个，分枝块最终只有1个。
对于上述分析索引之后的OPT_CMPR_COUNT字段表示最优压缩数，即对于该索引而言如果使用COMPRESS 2来压缩的话，可以得到最优的压缩效果。
同时OPT_CMPR_PCTSAVE字段值则表示最优压缩节省的空间百分比，针对第一次分析之后的结果，可以看到OPT_CMPR_PCTSAVE为33，即可以节省大约33%的空间。如下，压缩后1670153大约是压缩前2493786的2/3，即节约了1/3的空间：
SQL> select 1670153/2493786 from dual;
1670153/2493786
---------------
.669725871
SQL>
6 索引组织表(IOT Index-Organized Table)的INCLUDING和PCTTHRESHOLD参数选择
对于IOT表而言，如果在建表的语句中同时使用了INCLUDING和PCTTHRESHOLD参数的话，那么PCTTHRESHOLD参数的级别较高。
PCTTHRESHOLD：行中的数据量超过数据块的这个百分比时，行中其它的列则存放到OVERFLOW段中；
INCLUDING：行中从第一列直到INCLUDING子句中指定的列(包括该列)都存放在索引块中，其它的列存放到OVERFLOW段中。
即，对于大小为8K的数据块而言，有下面的IOT表：
SQL> create table iot1 2 (id number, 3 name char(2000), 4 addr char(2000), 5 salary number, 6 constraint iot1_pk primary key(id,name) 7 ) 8 organization index 9 pctthreshold 50 10 overflow 11 including addr; Table created. SQL>
那么，如果PCTTHRESHOLD参数指定为50的话，那么索引块中至多会使用4K的空间来存放主键字段和非主键字段，其它字段则存放到OVERFLOW段中，而会忽略此时的INCLUDING选项，并非将addr字段随主键字段一起存放，而是将其存放到溢出段中。
关于IOT表的学习，先到这个地方，以后有新的关于IOT表的知识，再补充在这里！