|
P6
|
发表于 2011-1-21 15:15:59
本帖最后由 oraunix 于 2011-1-21 15:50 编辑
IOT的压缩,看看下面的文章。
IOT: Index-Organized Table
索引组织表
含义即将表结构整体放入索引中,且是按照主键进行排序的。
创建:
create table emp_iot(
emp_no int,
emp_name varchar2(100),
dept_no int,
salary number(10,2),
constraint pk_empi primary key(emp_no, emp_name, dept_no))
organization index
[pctthreshold n/including colname] overflow tablespace fund_index;
参数:
pctthreshold: 溢出阀值。指定当块中的使用空间达到该值时,将溢出的数据存放到另外的段上。由参数overflow指定。
including:指定在哪个字段以后的字段放入溢出段。由参数overflow指定溢出的表空间。
分析该表的压缩度:
analyze table emp_iot validate structure cascade;
or
analyze index pk_empi validate structure;
查看分析结果
--将表改为非压缩模式:
SQL> alter table iot move nocompress;
Table altered
--分析索引
SQL> analyze index pk_iot validate structure;
Index analyzed
查看分析结果:
SQL> select ie.name, ie.used_space, ie.used_space*(1-ie.opt_cmpr_pctsave/100) after_compress,
2 ie.pct_used, ie.opt_cmpr_count, ie.opt_cmpr_pctsave
3 from index_stats ie
4 /
NAME USED_SPACE AFTER_COMPRESS PCT_USED OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------------------------------ ---------- -------------- ---------- -------------- ----------------
PK_IOT 2672239 1870567.3 90 2 30
字段used_space标识该索引使用了多少空间。
opt_cmpr_count是一个压缩建议值,表明压缩度为2时,可以节约30%的空间。
也就是压缩后空间可减少到:used_space*(1-30%),即:1870567.3
现在将压缩度改至2,看结果如何:
SQL> alter table iot move compress 2;
Table altered
--分析索引
SQL> analyze index pk_iot validate structure;
Index analyzed
--查看压缩结果:
SQL> select ie.name, ie.used_space, ie.used_space*(1-ie.opt_cmpr_pctsave/100) after_compress,
2 ie.pct_used, ie.opt_cmpr_count, ie.opt_cmpr_pctsave
3 from index_stats ie
4 /
NAME USED_SPACE AFTER_COMPRESS PCT_USED OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
------------------------------ ---------- -------------- ---------- -------------- ----------------
PK_IOT 1858487 1858487 89 2 0
可以看到现在已经压缩到1858487,与之前计算的1870567.3的估计值很接近。
压缩IOT不仅可以节省空间,还可以加快SQL语句的执行速度。
缺点就是在创建或压缩的时候需要占用比不压缩更多的CPU和时间。
但是从长远来看,这种消耗实际上是值得的。
|
|