- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
- ·
分类： oracle
2011-04-22 13:01:11
从oracle9ir2开始，oracle推出了压缩表技术（table compression），用于压缩数据表中的重复数据，以节省存储空间，压缩技术倾向于在数据仓库中使用。
压缩在数据块级生效，当数据表定义为压缩时，数据库在每个数据块上保留空间存储重复数据的单个拷贝，保留空间被称为符号表（symbol table）。此后在具体行上不必再存储这些重复数据，只需要存放指向符号表相应数据的指针，存储空间因此得以节省。
关于压缩表的基本介绍，参考otn上的文档:
我们看一下简单的测试:
|
[oracle@jumper oracle]$ sqlplus eygle/eygle sql*plus: release 9.2.0.4.0 - production on mon jun 26 16:07:24 2006 凯发app官方网站 copyright (c) 1982, 2002, oracle corporation. all rights reserved.
sql> create table test (c1 varchar2(20),c2 varchar2(20)); table created. sql> begin pl/sql procedure successfully completed. sql> create table test_compress compress as select * from test; table created. sql> select table_name,compression from user_tables where table_name like 'test%'; table_name compress sql> analyze table test compute statistics; table analyzed. sql> analyze table test_compress compute statistics; table analyzed. |
我们看一下两个表的空间使用情况:
|
sql> select table_name,blocks,empty_blocks from user_tables table_name blocks empty_blocks sql> select (28-4)/(18-6) from dual; (28-4)/(18-6) |
我们看到，压缩表只使用了常规表一半的空间。
我们转储一下数据块，看一下压缩表的存储结构：
|
sql> select segment_name,file_id,block_id,blocks from dba_extents segment_name file_id block_id blocks sql> alter system dump datafile 3 block 20; system altered. |
找到跟踪文件：
|
sql> @gettrcname.sql trace_file_name |
查看内容，首先看一下块头信息:
| data_block_dump,data header at 0xaa84e7c =============== tsiz: 0x1f80 hsiz: 0x5d2 pbl: 0x0aa84e7c bdba: 0x00c00014 76543210 flag=-0------ ntab=2 nrow=727 frre=-1 fsbo=0x5d2 fseo=0x1144 avsp=0x1a tosp=0x1a r0_9ir2=0x0 mec_kdbh9ir2=0x1 r1_9ir2=0x0 76543210 flag_9ir2=-------c fcls_9ir2[3]={ 0 32768 32768 } 0x1c:pti[0] nrow=1 offs=0 0x20:pti[1] nrow=726 offs=1 0x24:pri[0] offs=0x1f72 0x26:pri[1] offs=0x1f6d |
| tab 0, row 0, @0x1f72 tl: 14 fb: --h-fl-- lb: 0x0 cc: 2 col 0: [ 5] 65 79 67 6c 65 col 1: [ 4] 74 65 73 74 bindmp: 02 d6 02 cd 65 79 67 6c 65 cc 74 65 73 74 |
这个table 0只有一条记录，就是我们之前所说的符号表。
此后的记录才是真实数据，每条数据记录包含一个指针，指向符号表：
| tab 1, row 0, @0x1f6d tl: 5 fb: --h-fl-- lb: 0x0 cc: 2 col 0: [ 5] 65 79 67 6c 65 col 1: [ 4] 74 65 73 74 bindmp: 2c 00 01 02 00 tab 1, row 1, @0x1f68 tl: 5 fb: --h-fl-- lb: 0x0 cc: 2 col 0: [ 5] 65 79 67 6c 65 col 1: [ 4] 74 65 73 74 bindmp: 2c 00 01 02 00 |
这里的bindmp就是指针。
关于压缩表存储结构的进一步探讨可以参考:
biti_rainy 的 关于 9ir2 的 compress table 的研究
fuyuncat 的 数据段压缩（data segment compression）浅析
压缩表显然是通过cpu换取存储，存储的缩减必然导致存储和查询时压缩和解压缩的cpu消耗。
但是，i/o操作得以节约，我们看一下对以上2个表执行全表扫描的比较：
|
sql> set autotrace on count(*) execution plan statistics sql> select count(*) from test_compress;
statistics |
压缩表的一致性读只有17，较常规表的31大大减少。
压缩表是为数据仓库设计的特性，所以并不适合oltp系统，在发生更新时，压缩表会因行链接而迅速扩展空间使用。
请看简单测试:
|
sql> update test_compress set c1='oracle' where rownum <10; 9 rows updated. sql> commit; commit complete. sql> analyze table test_compress compute statistics; table analyzed. sql> select table_name,blocks,empty_blocks from user_tables table_name blocks empty_blocks |
具体可以参考wanghai 的文章: compress table