表压缩技术介绍

[size=large][/size]

[size=x-small] 上周了解了一下IBM的压缩技术,打算对比一下Oracle的表压缩技术做点研究,先讨论一下Oracle的表压缩技术.

从Oracle9iR2开始，Oracle推出了压缩表技术（table compression），用于压缩数据表中的重复数据，以节省存储空间，压缩技术倾向于在数据仓库中使用。

压缩在数据块级生效，当数据表定义为压缩时，数据库在每个数据块上保留空间存储重复数据的单个拷贝，保留空间被称为符号表（symbol table）。此后在具体行上不必再存储这些重复数据，只需要存放指向符号表相应数据的指针，存储空间因此得以节省。

关于压缩表的基本介绍，参考OTN上的文档:

http://www.oracle.com/technology/oramag/oracle/04-mar/o24tech_data.html

我们看一下简单的测试:

[oracle@jumper oracle]$ sqlplus eygle/eygle

SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jun 26 16:07:24 2006

Connected to:

Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production

With the Partitioning option

JServer Release 9.2.0.4.0 - Production

SQL> create table test (c1 varchar2(20),c2 varchar2(20));

Table created.

SQL> begin

2 for i in 1 .. 10000 loop

3 insert into test values(''eygle'',''test'');

4 end loop;

5 end;

6 /

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

------------------------------ --------

TEST DISABLED

TEST_COMPRESS ENABLED

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

2 where table_name like ''TEST%'';

TABLE_NAME BLOCKS EMPTY_BLOCKS

------------------------------ ---------- ------------

TEST 28 4

TEST_COMPRESS 18 6

SQL> select (28-4)/(18-6) from dual;

(28-4)/(18-6)

-------------

我们看到，压缩表只使用了常规表一半的空间。

我们转储一下数据块，看一下压缩表的存储结构：

SQL> select segment_name,file_id,block_id,blocks from dba_extents

2 where segment_name=''TEST_COMPRESS'';

SEGMENT_NAME FILE_ID BLOCK_ID BLOCKS

-------------------- ---------- ---------- ----------

TEST_COMPRESS 3 17 8

TEST_COMPRESS 3 25 8

TEST_COMPRESS 3 33 8

SQL> alter system dump datafile 3 block 20;

System altered.

找到跟踪文件：

SQL> @gettrcname.sql

TRACE_FILE_NAME

-------------------------------------------------------------------

/opt/oracle/admin/eygle/udump/eygle_ora_20984.trc

查看内容，首先看一下块头信息:

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

我们看到这个Block中的ntab =2 也就是存在2张表，从下面可以找到table 0的信息: 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 的研究

http://www.itpub.net/showthread.php?threadid=197403

fuyuncat 的数据段压缩（Data Segment Compression）浅析

http://fuyuncat.itpub.net/post/5203/45991

压缩表显然是通过CPU换取存储，存储的缩减必然导致存储和查询时压缩和解压缩的CPU消耗。

但是，I/O操作得以节约，我们看一下对以上2个表执行全表扫描的比较：

SQL> set autotrace on

SQL> select count(*) from test;

COUNT(*)

----------

10000

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=4 Card=1)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF ''TEST'' (Cost=4 Card=10000)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

31 consistent gets

0 physical reads

0 redo size

379 bytes sent via SQL*Net to client

503 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL> select count(*) from test_compress;

COUNT(*)

----------

10000

Execution Plan

----------------------------------------------------------

0 SELECT STATEMENT Optimizer=CHOOSE (Cost=3 Card=1)

1 0 SORT (AGGREGATE)

2 1 TABLE ACCESS (FULL) OF ''TEST_COMPRESS'' (Cost=3 Card=10000)

Statistics

----------------------------------------------------------

0 recursive calls

0 db block gets

17 consistent gets

0 physical reads

0 redo size

379 bytes sent via SQL*Net to client

503 bytes received via SQL*Net from client

2 SQL*Net roundtrips to/from client

0 sorts (memory)

0 sorts (disk)

1 rows processed

压缩表的一致性读只有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

2 where table_name like ''TEST%'';

TABLE_NAME BLOCKS EMPTY_BLOCKS

------------------------------ ---------- ------------

TEST 28 4

TEST_COMPRESS 24 0[/size]

猜你喜欢