这个iot表是压缩的还是非压缩的???

相老师您好:帮我确认一下这是个怎么样的iot表。从user_tables的compression字段看是disable的,但是这儿又有compress参数!
用 dbms_metadata.get_ddl 导出的表结构如下:
CREATE TABLE "GENREPORT"."PENDING_AGG"
   (    "REP_VIEW_ID" NUMBER(*,0) NOT NULL ENABLE,
        "AGG_KEY" VARCHAR2(20) NOT NULL ENABLE,
        "CNUMBER" NUMBER NOT NULL ENABLE,
         CONSTRAINT "PK_PENDING_AGG" PRIMARY KEY ("REP_VIEW_ID", "AGG_KEY", "CNU
MBER")
ENABLE,
         SUPPLEMENTAL LOG GROUP "GGS_PENDING_AGG_52179" ("REP_VIEW_ID", "AGG_KEY
", "CNU
MBER") ALWAYS,
         CONSTRAINT "FK_PENDING__VIEW_T" FOREIGN KEY ("REP_VIEW_ID")
          REFERENCES "GENREPORT"."REPORT_VIEW" ("REP_VIEW_ID") ENABLE
   ) ORGANIZATION INDEX COMPRESS 1 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 "GENREPORT"
PCTTHRESHOLD 50  
标签: 暂无标签
wayneshen730

写了 2 篇文章,拥有财富 22,被 3 人关注

转播转播 分享分享 分享淘帖
回复

使用道具

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和时间。
但是从长远来看,这种消耗实际上是值得的。
回复

使用道具

P3 | 发表于 2011-1-20 20:19:56
  怎么样的iot表才算是压缩iot表的呀?
回复

使用道具

P6 | 发表于 2011-1-20 15:34:46
应该没有压缩。
回复

使用道具

您需要登录后才可以回帖 登录 | 加入社区

本版积分规则

意见
反馈