oracle了解一下压缩表.doc

数据被压缩的原理在于，对于数据块里的重复值来说，只保留一份。保存在数据块里的压缩数据是自我包含的。也就是说，对于将压缩的数据进行解压来说，所有需要的信息都在数据块里了，而不需要参考数据块以外的其他数据。数据块里的所有重复数据行和数据列都只存放一次，并放在数据块的开始部分，这块区域叫做数据块的symbol table。也就是说，同一个数据块里放了两个表的数据。这一点有点像class table。数据行里如果存在重复的值，则该重复值去掉，并在原来的位置上放了一个很短的引用，指向symbol table。除了数据块开始部分的symbol table以外，压缩数据块与普通的数据块没什么两样。注意，在9i里，压缩表在创建以后就不能修改结构的，而10g则没有这个限制了，但是不能对添加的列提供缺省值。对于压缩数据块的访问来说，并没有很消耗资源的解压缩操作。这也就是说，在考虑是否要启用压缩时，并不需要考虑对于查询性能的影响。只能在进行批量数据加载的时候，完成压缩操作。在加载数据并压缩过程中，CPU资源的消耗会有50%的增长。只有当数据批量插入或加载的时候完成压缩，这些操作包括：SQL*Loader的直接路径加载。CREATE TABLECOMPRESS AS SELECT。并行insert或带有append提示的串行insert。你也可以发出ALTER TABLEMOVE COMPRESS，从而将表里已有的数据进行压缩。对于压缩表的update操作的效率极其低下，如果一个表要经常被update，则不应该对该表启用压缩。因为update时，需要先将数据解压，然后对解压后的数据进行更新，更新结束以后再次压缩。除了LOB以外的数据类型都可以被压缩。另外，如果表里的列超过255个，则压缩被禁用。也提供对索引的压缩，包括B树索引和bitmap索引，以及IOT表。来了解一下压缩表的内部结构。SQL create table t_seed as2select chr(trunc(dbms_random.value(65,67) c1,chr(trunc(dbms_random.value(65,67) c2,3trunc(dbms_random.value(0,2) c1flag,trunc(dbms_random.value(0,2) c2flag4from dba_objects where rownum create table t_comp_1 compress as2select decode(c1flag,1,lpad(c1,10,c1),null) as c1,3decode(c2flag,1,lpad(c2,10,c2),null) as c2 from t_seed;表已创建。SQL select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,2dbms_rowid.rowid_block_number(rowid) as block# from t_comp_1 order by file#,block#;FILE#BLOCK#- -4760447605SQL alter system dump datafile 4 block 7604;系统已更改。data_block_dump,data header at 0xcc19a7c=tsiz: 0x1f80hsiz: 0x5cepbl: 0x0cc19a7cbdba: 0x01001db476543210flag=-0-ntab=2这里的2说明该数据块里有2个表，一个symbol table，一个实际的表。nrow=725frre=-1fsbo=0x5cefseo=0x1147avsp=0x3dtosp=0x3dr0_9ir2=0x0mec_kdbh9ir2=0x9这里的9说明该数据块里重复值有9种情况。76543210shcf_kdbh9ir2=-76543210flag_9ir2=-R-Cfcls_9ir23= 0 32768 32768 0x1c:pti0nrow=11offs=0这部分说明symbol table里有6条记录。0x20:pti1nrow=717offs=11这部分说明该数据块里存放的实际表里的记录行数为717行。0x24:pri0offs=0x1f610x26:pri1offs=0x1f5c.tab 0, row 0, 0x1f61tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: *NULL*col1: *NULL*bindmp:00 a7 02 ff fftab 0, row 1, 0x1f5ctl: 5 fb: -H-FL- lb: 0x0cc: 2col0: *NULL*col1: 1042 42 42 42 42 42 42 42 42 42bindmp: 00 50 02 ff0atab 0, row 2, 0x1f57tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: *NULL*col1: 1041 41 41 41 41 41 41 41 41 41bindmp: 006c02 ff 09tab 0, row 3, 0x1f52tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1042 42 42 42 42 42 42 42 42 42col1: *NULL*bindmp: 00 55 020afftab 0, row 4, 0x1f4dtl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1042 42 42 42 42 42 42 42 42 42col1: 1042 42 42 42 42 42 42 42 42 42bindmp: 00 34 020a0atab 0, row 5, 0x1f48tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1042 42 42 42 42 42 42 42 42 42col1: 1041 41 41 41 41 41 41 41 41 41bindmp: 00 22 020a09tab 0, row 6, 0x1f43tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1041 41 41 41 41 41 41 41 41 41col1: *NULL*bindmp: 00 5b 02 09 fftab 0, row 7, 0x1f3etl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1041 41 41 41 41 41 41 41 41 41col1: 1042 42 42 42 42 42 42 42 42 42bindmp: 002c02 090atab 0, row 8, 0x1f39tl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1041 41 41 41 41 41 41 41 41 41col1: 1041 41 41 41 41 41 41 41 41 41bindmp: 00 38 02 09 09tab 0, row 9, 0x1f66tl: 13 fb: -H-FL- lb: 0x0cc: 1col0: 1041 41 41 41 41 41 41 41 41 41bindmp: 00 06 d2 41 41 41 41 41 41 41 41 41 41tab 0, row 10, 0x1f73tl: 13 fb: -H-FL- lb: 0x0cc: 1col0: 1042 42 42 42 42 42 42 42 42 42bindmp: 00 06 d2 42 42 42 42 42 42 42 42 42 42以上tab 0的部分就是所谓的symbol table里所存放的记录了。可以看到一共有11条记录。实际就是对c1和c2这两列所存在的值的穷举，如下所示：可能的情况C1列C2列1AAAAAAAAAANull2BBBBBBBBBBNull3NullAAAAAAAAAA4NullBBBBBBBBBB5AAAAAAAAAAAAAAAAAAAA6AAAAAAAAAABBBBBBBBBB7BBBBBBBBBBAAAAAAAAAA8BBBBBBBBBBBBBBBBBBBB9NullNull而在该数据块里的每条记录就是对上面这9种情况的描述，不过它穷举出来的情况要更多点。多出来的也就是最后两条cc为1的记录。也就是说有可能只压缩一列。在我们这个例子里，因为只有两个列，所以没有这种情况。如果表里的列很多，则有可能只压缩一列。在tab 0里的每条记录里，记录了c1列和c2列的可能的取值，同时还记录了bindmp，这表示该种组合的一些元数据。比如对于symbol table里的row 4来说：tab 0, row 4, 0x1f4dtl: 5 fb: -H-FL- lb: 0x0cc: 2col0: 1042 42 42 42 42 42 42 42 42 42col1: 1042 42 42 42 42 42 42 42 42 42bindmp: 00 34 020a0a前两个字节表示该数据块里有多少条记录属于该组合。这里为十六进制的00 34，换算成十进制，也就是52。说明在该数据块里的717条记录当中，有52条记录的(c1,c2)=(BBBBBBBBBB,BBBBBBBBBB)。02表示压缩的列的个数为2个列。我们来验证一下：SQL select count(*) from(2select c1,c2 from t_comp_1 where rownum create table t_comp_2 compress as2select decode(c1flag,1,lpad(c1,10,c1),null) as c1,rownum id1,3decode(c2flag,1,lpad(c2,10,c2),null) as c2,4chr(trunc(dbms_random.value(65,80) c3 from t_seed;表已创建。SQL select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,2dbms_rowid.rowid_block_number(rowid) as block# from t_comp_2 order by file#,block#;FILE#BLOCK#- -4690046901SQL alter system dump datafile 4 block 6900;系统已更改。打开转储文件，可以看到下面的部分：r0_9ir2=0x0mec_kdbh9ir2=0x1876543210shcf_kdbh9ir2=-76543210flag_9ir2=-R-OCfcls_9ir24= 0 32768 32768 32768 perm_9ir24= 0 3 1 2 多出了这一行。这一行非常重要，因为在压缩表中，oracle会修改列的排列顺序。非压缩表里，列在物理存放的时候，按照数据字典里记录的顺序，也就是col1、col2、col3.。比如：SQL desc t_comp_2名称是否为空?类型- - -C1VARCHAR2(2)ID1NUMBERC2VARCHAR2(2)C3VARCHAR2(2)也就是说，正常表来说，在数据块里存放列时，会这样放：col 0 XXXXXXX-表示放的是C1列的值col 1 XXXXXXX-表示放的是ID1列的值col 2 XXXXXXX-表示放的是C2列的值col 3 XXXXXXX-表示放的是C3列的值但是，在压缩表里，col 0已经不表示c1列的值了，col 1也不是ID1列的值。怎么对应呢，就是从这里的perm_9ir24= 0 3 1 2 来对应。这里的0、3、1、2表示物理存储时的列的下标。也就是说col 0对应数据字典里的col 1，在这里也就是C1列；col 3对应I