--IOT compress参数优化存储空间
EODA@PROD1> 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 /
Table created.
EODA@PROD1>
EODA@PROD1> analyze index iot_pk validate structure; --这个命令会填写一个名为INDEX_STATS的动态性能视图
Index analyzed.
EODA@PROD1>
EODA@PROD1> select lf_blks, br_blks, used_space, opt_cmpr_count, opt_cmpr_pctsave
2 from index_stats;
LF_BLKS BR_BLKS USED_SPACE OPT_CMPR_COUNT OPT_CMPR_PCTSAVE
---------- ---------- ---------- -------------- ----------------
435 3 3123453 2 33
/* OPT_CMPR_COUNT NUMBER Optimal key compression length 最优压缩列数
OPT_CMPR_PCTSAVE NUMBER Corresponding space savings after an ANALYZE 最优压缩空间节省百分比
Oracle告诉我们当compress为2时为最优,而且能优化33%空间。
现在NOCOMPRESS状态下索引使用了435个叶块,并使用了3个分支块用来在索引结构中导航所用的块来找到叶块,使用了3123453个字节。
EODA@PROD1> select (1-0.33)* 3123453 total from dual;
TOTAL
----------
2092713.51 --模拟计算Oracle预估的结果 */
--先compress设置为1进行观察
EODA@PROD1>
EODA@PROD1> alter table iot move compress 1;
Table altered.
EODA@PROD1> analyze index iot_pk validate structure;
Index analyzed.
EODA@PROD1>
EODA@PROD1> 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
---------- ---------- ---------- -------------- ----------------
377 3 2704181 2 22
--先compress设置为2进行观察
EODA@PROD1> alter table iot move compress 2;
Table altered.
EODA@PROD1>
EODA@PROD1> analyze index iot_pk validate structure;
Index analyzed.
EODA@PROD1>
EODA@PROD1> 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
---------- ---------- ---------- -------------- ----------------
290 3 2081735 2 0
<pre name="code" class="sql">结果与Oracle预估的相当准确,索引占了相当大的空间这说明IOT从名字上看是表但实际上完全是一个索引段。
结果与Oracle预估的相当准确,索引占了相当大的空间这说明IOT从名字上看是表但实际上完全是一个索引段。