相老师您好：帮我确认一下这是个怎么样的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  

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

  怎么样的iot表才算是压缩iot表的呀？

应该没有压缩。