数据被压缩的原理在于,对于数据块里的重复值来说,只保留一份。保存在数据块里的压缩数据是自我包含的。也就是说,对于将压缩的数据进行解压来说,所有需要的信息都在数据块里了,而不需要参考数据块以外的其他数据。
数据块里的所有重复数据行和数据列都只存放一次,并放在数据块的开始部分,这块区域叫做数据块的symbol table。也就是说,同一个数据块里放了两个表的数据。这一点有点像class table。数据行里如果存在重复的值,则该重复值去掉,并在原来的位置上放了一个很短的引用,指向symbol table。除了数据块开始部分的symbol table以外,压缩数据块与普通的数据块没什么两样。注意,在9i里,压缩表在创建以后就不能修改结构的,而10g则没有这个限制了,但是不能对添加的列提供缺省值。
对于压缩数据块的访问来说,并没有很消耗资源的解压缩操作。这也就是说,在考虑是否要启用压缩时,并不需要考虑对于查询性能的影响。只能在进行批量数据加载的时候,完成压缩操作。在加载数据并压缩过程中,CPU资源的消耗会有50%的增长。
只有当数据批量插入或加载的时候完成压缩,这些操作包括:
·SQL*Loader的直接路径加载。
·CREATE TABLE … COMPRESS AS SELECT。
·并行insert或带有append提示的串行insert。你也可以发出ALTER TABLE…MOVE COMPRESS,从而将表里已有的数据进行压缩。
对于压缩表的update操作的效率极其低下,如果一个表要经常被update,则不应该对该表启用压缩。因为update时,需要先将数据解压,然后对解压后的数据进行更新,更新结束以后再次压缩。
除了LOB以外的数据类型都可以被压缩。另外,如果表里的列超过255个,则压缩被禁用。也提供对索引的压缩,包括B树索引和bitmap索引,以及IOT表。
来了解一下压缩表的内部结构。
SQL> create table t_seed as
2 select chr(trunc(dbms_random.value(65,67))) c1,chr(trunc(dbms_random.value(65,67))) c2,
3 trunc(dbms_random.value(0,2)) c1flag,trunc(dbms_random.value(0,2)) c2flag
4 from dba_objects where rownum<=1000;
表已创建。
SQL> create table t_comp_1 compress as
2 select decode(c1flag,1,lpad(c1,10,c1),null) as c1,
3 decode(c2flag,1,lpad(c2,10,c2),null) as c2 from t_seed;
表已创建。
SQL> select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,
2 dbms_rowid.rowid_block_number(rowid) as block# from t_comp_1 order by file#,block#;
FILE# BLOCK#
---------- ----------
4 7604
4 7605
SQL> alter system dump datafile 4 block 7604;
系统已更改。
data_block_dump,data header at 0xcc19a7c
===============
tsiz: 0x1f80
hsiz: 0x5ce
pbl: 0x0cc19a7c
bdba: 0x01001db4
76543210
flag=-0------
ntab=2 这里的2说明该数据块里有2个表,一个symbol table,一个实际的表。
nrow=725
frre=-1
fsbo=0x5ce
fseo=0x1147
avsp=0x3d
tosp=0x3d
r0_9ir2=0x0
mec_kdbh9ir2=0x9 这里的9说明该数据块里重复值有9种情况。
76543210
shcf_kdbh9ir2=----------
76543210
flag_9ir2=--R----C
fcls_9ir2[3]={ 0 32768 32768 }
0x1c:pti[0] nrow=11 offs=0 这部分说明symbol table里有6条记录。
0x20:pti[1] nrow=717 offs=11 这部分说明该数据块里存放的实际表里的记录行数为717行。
0x24:pri[0] offs=0x1f61
0x26:pri[1] offs=0x1f5c
......................
tab 0, row 0, @0x1f61
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: *NULL*
col 1: *NULL*
bindmp: 00 a7 02 ff ff
tab 0, row 1, @0x1f5c
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: *NULL*
col 1: [10] 42 42 42 42 42 42 42 42 42 42
bindmp: 00 50 02 ff 0a
tab 0, row 2, @0x1f57
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: *NULL*
col 1: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 6c 02 ff 09
tab 0, row 3, @0x1f52
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 42 42 42 42 42 42 42 42 42 42
col 1: *NULL*
bindmp: 00 55 02 0a ff
tab 0, row 4, @0x1f4d
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 42 42 42 42 42 42 42 42 42 42
col 1: [10] 42 42 42 42 42 42 42 42 42 42
bindmp: 00 34 02 0a 0a
tab 0, row 5, @0x1f48
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 42 42 42 42 42 42 42 42 42 42
col 1: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 22 02 0a 09
tab 0, row 6, @0x1f43
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 41 41 41 41 41 41 41 41 41 41
col 1: *NULL*
bindmp: 00 5b 02 09 ff
tab 0, row 7, @0x1f3e
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 41 41 41 41 41 41 41 41 41 41
col 1: [10] 42 42 42 42 42 42 42 42 42 42
bindmp: 00 2c 02 09 0a
tab 0, row 8, @0x1f39
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 41 41 41 41 41 41 41 41 41 41
col 1: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 38 02 09 09
tab 0, row 9, @0x1f66
tl: 13 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 06 d2 41 41 41 41 41 41 41 41 41 41
tab 0, row 10, @0x1f73
tl: 13 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [10] 42 42 42 42 42 42 42 42 42 42
bindmp: 00 06 d2 42 42 42 42 42 42 42 42 42 42
以上tab 0的部分就是所谓的symbol table里所存放的记录了。可以看到一共有11条记录。实际就是对c1和c2这两列所存在的值的穷举,如下所示:
可能的情况 | C1列 | C2列 |
1 | AAAAAAAAAA | Null |
2 | BBBBBBBBBB | Null |
3 | Null | AAAAAAAAAA |
4 | Null | BBBBBBBBBB |
5 | AAAAAAAAAA | AAAAAAAAAA |
6 | AAAAAAAAAA | BBBBBBBBBB |
7 | BBBBBBBBBB | AAAAAAAAAA |
8 | BBBBBBBBBB | BBBBBBBBBB |
9 | Null | Null |
而在该数据块里的每条记录就是对上面这9种情况的描述,不过它穷举出来的情况要更多点。
多出来的也就是最后两条cc为1的记录。也就是说有可能只压缩一列。在我们这个例子里,因为只有两个列,所以没有这种情况。如果表里的列很多,则有可能只压缩一列。
在tab 0里的每条记录里,记录了c1列和c2列的可能的取值,同时还记录了bindmp,这表示该种组合的一些元数据。比如对于symbol table里的row 4来说:
tab 0, row 4, @0x1f4d
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 42 42 42 42 42 42 42 42 42 42
col 1: [10] 42 42 42 42 42 42 42 42 42 42
bindmp: 00 34 02 0a 0a
前两个字节表示该数据块里有多少条记录属于该组合。这里为十六进制的00 34,换算成十进制,也就是52。说明在该数据块里的717条记录当中,有52条记录的(c1,c2)=(‘BBBBBBBBBB’,’ BBBBBBBBBB’)。02表示压缩的列的个数为2个列。
我们来验证一下:
SQL> select count(*) from(
2 select c1,c2 from t_comp_1 where rownum<=717)
3 where c1='BBBBBBBBBB' and c2='BBBBBBBBBB';
COUNT(*)
----------
52
tab 0以后的部分就是tab 1,这部分就是数据块里实际存放的记录了。
tab 1, row 0, @0x1f34
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: [10] 42 42 42 42 42 42 42 42 42 42
col 1: *NULL*
bindmp: 2c 00 01 02 03
tab 1, row 1, @0x1f2f
tl: 5 fb: --H-FL-- lb: 0x0 cc: 2
col 0: *NULL*
col 1: *NULL*
bindmp: 2c 00 01 02 00
..................
转储的时候,进行了解压。把c1和c2的值都显示出来。实际物理存放的值是:
bindmp: 2c 00 01 02 03
..................
也就是对每条记录来说,只占用了5个字节。其中,2c 00应该表示symbol table的物理地址。02表示压缩了2个字段。03表示在symbol table里的记录行号。这里的03也就是symbol table里的row 3所记录的c1和c2的值。换句话说,该表里的第一条记录的(c1,c2)也就等于('BBBBBBBBBB', Null)。
这时再创建一个压缩表,该表里多加两个列:
SQL> create table t_comp_2 compress as
2 select decode(c1flag,1,lpad(c1,10,c1),null) as c1,rownum id1,
3 decode(c2flag,1,lpad(c2,10,c2),null) as c2,
4 chr(trunc(dbms_random.value(65,80))) c3 from t_seed;
表已创建。
SQL> select distinct dbms_rowid.rowid_relative_fno(rowid) as file#,
2 dbms_rowid.rowid_block_number(rowid) as block# from t_comp_2 order by file#,block#;
FILE# BLOCK#
---------- ----------
4 6900
4 6901
SQL> alter system dump datafile 4 block 6900;
系统已更改。
打开转储文件,可以看到下面的部分:
r0_9ir2=0x0
mec_kdbh9ir2=0x18
76543210
shcf_kdbh9ir2=----------
76543210
flag_9ir2=--R---OC
fcls_9ir2[4]={ 0 32768 32768 32768 }
perm_9ir2[4]={ 0 3 1 2 } 多出了这一行。
这一行非常重要,因为在压缩表中,oracle会修改列的排列顺序。非压缩表里,列在物理存放的时候,按照数据字典里记录的顺序,也就是col1、col2、col3....。比如:
SQL> desc t_comp_2
名称 是否为空? 类型
----------------------------------------- -------- ----------------------------
C1 VARCHAR2(2)
ID1 NUMBER
C2 VARCHAR2(2)
C3 VARCHAR2(2)
也就是说,正常表来说,在数据块里存放列时,会这样放:
col 0 XXXXXXX ->表示放的是C1列的值
col 1 XXXXXXX ->表示放的是ID1列的值
col 2 XXXXXXX ->表示放的是C2列的值
col 3 XXXXXXX ->表示放的是C3列的值
但是,在压缩表里,col 0已经不表示c1列的值了,col 1也不是ID1列的值。怎么对应呢,就是从这里的perm_9ir2[4]={ 0 3 1 2 }来对应。这里的0、3、1、2表示物理存储时的列的下标。也就是说col 0对应数据字典里的col 1,在这里也就是C1列;col 3对应ID1;col 1对应C2;col 2对应C3。
找到tab 1部分,比如:
tab 1, row 0, @0x1ea9
tl: 9 fb: --H-FL-- lb: 0x0 cc: 4
col 0: [10] 42 42 42 42 42 42 42 42 42 42 ->表示放的是C1列的值
col 1: *NULL* ->表示放的是C2列的值
col 2: [ 1] 49 ->表示放的是C3列的值
col 3: [ 2] c1 02 ->表示放的是ID1列的值
bindmp: 2c 00 03 03 12 28 ca c1 02 ->这里2c 00表示symbol table的地址。而03
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/9842/viewspace-344546/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/9842/viewspace-344546/