11GR2 Advanced Compress之OLTP Table Compress的研究

viadeazhu · 发表于 2009-10-16 22:29

原文见blog：
http://space.itpub.net/15415488/viewspace-616769

11GR2 Advanced Compress是非常值得购买的11G新特性。他引入了一种对于Oracle来说全新的压缩算法，更加合理和高效。
为什么说他值得购买？因为他需要的license不在Enterprise Edition License之中，需要额外掏钱。
而他包含了若干个方面的压缩，其中又不乏我们所期望的特性。
1.最常见的应该就是OLTP table compression，支持了传统的DML语句。
2.其次也会常常用到的是Backup Data compression，对Rman backup files、Datapump Files都有支持，能够给我们带来更节省的备份空间。更爽的是，compress是inline发生的，也就是说不需要我们认为的解压，比如说impdp就能自动识别expdp的压缩文件。
3.第三我觉得也会应用到的是Network Traffic Compression。因为现在在我们生产数据库使用dataguard常常会出现delay几分钟的情况出现，有时是因为network traffic bottleneck。但是如果使用Network Traffic Compression，redo在dataguard中传输也会被压缩和解压了，帮我们解决了这个头疼的问题。
这篇文章，我做了一些针对OLTP table compress的实验和研究，主要从三方面：微观上、性能上和宏观上。
<从微观上分析>
分析之埃?颐窍攘私庀翺LTP table compress的原理。
当我们对一个表使用alter table xxx compress for OLTP语句时，就跟传统compress一样，对已有的数据不受影响。
但是他对一个block中新insert或update的行最开始也不受影响，知道这个block达到PCTFREE时才触发compress。
于是，现在新的compress其实就是从老的方法：对每条新增的行做compress，变成了对一个block中的所有行批量处理。
这样就让大部分的insert/update语句没有性能上的损失，只对非常不幸的insert/update导致某个block刚好达到PCTFREE的语句有一些overhead。
当一个block由于触发压缩，而导致block的数据又低于PCTFREE的临界点后，这个block又可以接受更多的数据，会又一次达到PCTFREE，就会又一次压缩。
于是我从微观上的实验就是验证OLTP compress的这种算法的。
1.Before compression
SQL> create table haocompress
  2  (id1 char(200),id2 char(200),id3 char(200),id4 char(200))
  3  pctfree 20 pctused 50;
Table created.
我建立了一行800字节的表，他的pctfree是20%，我的block size是8k。也就是说从理论上当第一个block达到80%满的时候发生第一次压缩。也就是数据量达到8k*80%=6.4K左右。
也就是大约插入了8行的时候。首先插入2行。
insert into haocompress values('haozhu','zhuhao','1234','4321');
insert into haocompress values('haozhu','haozhu','4321','1234');
SQL> select EXTENT_ID,FILE_ID,BLOCK_ID,BLOCKS from dba_extents where SEGMENT_NAME='HAOCOMPRESS';
EXTENT_ID FILE_ID BLOCK_ID    BLOCKS
---------- ---------- ---------- ----------
      0       4       128       8

SQL> alter system dump datafile 4 block min 128 block max 131;
System altered.
tab 0, row 0, @0x1c79
col  0: [200]
68 61 6f 7a 68 75
col  1: [200]
7a 68 75 68 61 6f
col  2: [200]
31 32 33 34
col  3: [200]
34 33 32 31

tab 0, row 1, @0x1952
col  0: [200]
68 61 6f 7a 68 75
col  1: [200]
68 61 6f 7a 68 75
col  2: [200]
34 33 32 31
col  3: [200]
31 32 33 34

以上是先观察下不压缩时的数据格式。

2.After enable compress for OLTP
SQL> alter table haocompress compress for OLTP;
Table altered.
SQL> select COMPRESSION,COMPRESS_FOR from dba_tables
  2  where table_name='HAOCOMPRESS';
COMPRESS COMPRESS_FOR
-------- ------------
ENABLED  OLTP
对这个表应用OLTP compress，接着来用我独门的show_space工具来看看：
SQL> exec hao_show_space('HAOCOMPRESS');
##################################################
--------hao_show_space kit created by Hao---------
##################################################
MSSM tablespace:
The segment space usage for TABLE "HAOZHU_USER.HAOCOMPRESS"
##################################################
UNUSED BLOCKS...........................6
UNUSED Bytes............................49152
------------------------HWM------------------------
Free Blocks.............................1
Used Blocks.............................1
##################################################
Total Blocks............................8
Total Bytes.............................65536
##################################################
Last Used Ext FileId....................4
Last Used Ext BlockId...................128
Last Used Block.........................2
SQL> alter system dump datafile 4 block min 128 block max 131;
System altered.
从dump文件可以看见，对已有数据并没有压缩发生。

3.insert one more row
insert into haocompress values('haozhu','zhuhao','7890','4321');
第三行仍然没有没有压缩：
tab 0, row 2, @0x162b
col  0: [200]
68 61 6f 7a 68 75
col  1: [200]
7a 68 75 68 61 6f
col  2: [200]
37 38 39 30
col  3: [200]
34 33 32 31

4.insert more rows reaching PCTFREE
我的一行是800字节，blocksize是8192字节。
PCTFREE是20,那么就是8192*80%=6553.6字节满时触发压缩。
也就是插入第6553.6/800=8行时触发。

(4)insert into haocompress values('haozhu','zhuhao2','7890','4321');
(5)insert into haocompress values('haozhu','zhuhao3','7890','0000');
(6)insert into haocompress values('haozhu2','zhuhao','3333','1234');
(7)insert into haocompress values('haozhu3','zhuhao','3333','1234');
(8)insert into haocompress values('haozhu3','zhuhao8','444','8888');
tab 0, row 0, @0x1c6c
col  0: [200]
68 61 6f 7a 68 75  (haozhu)
bindmp: 00 06 fa 00 c8 68 61 6f 7a 68 75
tab 0, row 1, @0x1ed3
col  0: [200]
34 33 32 31       (4321)
bindmp: 00 04 fa 00 c8 34 33 32 31
tab 0, row 2, @0x1d39
col  0: [200]
7a 68 75 68 61 6f  (zhuhao)
bindmp: 00 04 fa 00 c8 7a 68 75 68 61 6f
tab 0, row 3, @0x1e06
col  0: [200]
31 32 33 34       (1234)
bindmp: 00 04 fa 00 c8 31 32 33 34
tab 0, row 4, @0x1b9f
col  0: [200]
37 38 39 30       (7890)
bindmp: 00 03 fa 00 c8 37 38 39 30
tab 0, row 5, @0x1ad2
col  0: [200]
33 33 33 33       (3333)
bindmp: 00 02 fa 00 c8 33 33 33 33
-------
tab 1, row 0, @0x1aca
bindmp: 2c 00 04 04 00 02 03 01
(haozhu,zhuhao,1234,4321)
tab 1, row 1, @0x1ac2
bindmp: 2c 00 04 04 00 00 01 03
(haozhu,haozhu,4321,1234)
tab 1, row 2, @0x1aba
bindmp: 2c 00 04 04 00 02 04 01
(haozhu,zhuhao,7890,4321)
tab 1, row 3, @0x19ea
bindmp: 2c 00 04 04 00 c9 7a 68 75 68 61 6f 32
(haozhu,zhuhao2,7890,4321)
tab 1, row 4, @0x1852
bindmp: 2c 00 04 04 00 c9 7a 68 75 68 61 6f 33
(haozhu,zhuhao3,7890,0000)

tab 1, row 5, @0x1782
bindmp: 2c 00 04 04 c9 68 61 6f 7a 68 75 32
(haozhu2,zhuhao,3333,1234)
tab 1, row 6, @0x16b2
bindmp: 2c 00 04 04 c9 68 61 6f 7a 68 75 33
(haozhu3,zhuhao,3333,1234)
tab 1, row 7, @0x1387
bindmp: 2c 02 03 02 ca 68 61 6f 7a 68 75 33
(haozhu3,zhuhao8,444,8888)
以上就是插入第八行后的block dump结果。
果然，当插入第八行的时候发生了压缩，这点得到了论证。
而且在这个block中，Oracle新增了一个表，就是红色部分，他就是所谓的Signal table，存放压缩表中相同的字段的片段。
现在观察蓝色部分，这才是我们正在的数据表，他仅仅存放了一个叫做bindmp的地址，而这个地址就指向了前面signal table的不同位置。具体这个地址如何解析，我没有深究。
在这里我要着重阐明几点：
1.signal table的每一行可以被compressed table的不同列引用。例如“haozhu”字样在以上的表中的第一列和第二列一共出现过6次，于是我们看：
tab 0, row 0, @0x1c6c
col  0: [200]
68 61 6f 7a 68 75  (haozhu)
bindmp: 00 06 fa 00 c8 68 61 6f 7a 68 75
原来，bindmp的第二个byte就是存放这个字样出现过多少次的。（也有可能第一个byte为00也是作为他的高位存在）。
2.signal table的排列顺序是按引用次数来排的。我们可以看出，引用次数从6到2递减排列。
3.signal table的某一个signal也可以作为前缀被引用。例如在compressed table中的“haozhu3”这样的一行，也其实引用了“haozhu”的signal（只是没有算在“haozhu”signal被引用的次数中）。

<从performance上分析>
看完了从微观上分析OLTP compress的新算法后，我们从update、insert、select等DML语句来看看他的性能情况。
是不是有很高的overhead？是不是真如Oracle自己号称的那样呢？

5.insert much more rows and compare with non-compress table
SQL> select count(*) from haocompress;
  COUNT(*)
----------
   16384
SQL> create table haonocompress as select * from haocompress;
Table created.

SQL>  exec hao_show_space('HAOCOMPRESS');
##################################################
--------hao_show_space kit created by Hao---------
##################################################
MSSM tablespace:
The segment space usage for TABLE "HAOZHU_USER.HAOCOMPRESS"
##################################################
UNUSED BLOCKS...........................38
UNUSED Bytes............................311296
------------------------HWM------------------------
Free Blocks.............................2
Used Blocks.............................600
##################################################
Total Blocks............................640
Total Bytes.............................5242880
##################################################
Last Used Ext FileId....................4
Last Used Ext BlockId...................640
Last Used Block.........................90
SQL> exec hao_show_space('HAONOCOMPRESS');
##################################################
--------hao_show_space kit created by Hao---------
##################################################
MSSM tablespace:
The segment space usage for TABLE "HAOZHU_USER.HAONOCOMPRESS"
##################################################
UNUSED BLOCKS...........................127
UNUSED Bytes............................1040384
------------------------HWM------------------------
Free Blocks.............................0
Used Blocks.............................2049
##################################################
Total Blocks............................2176
Total Bytes.............................17825792
##################################################
Last Used Ext FileId....................4
Last Used Ext BlockId...................2816
Last Used Block.........................1

6.insert performance
SQL> create table HAOCOMPRESS compress for oltp
  2  as
  3  select * from dba_objects;
Table created.
SQL> create table HAONOCOMPRESS
  2  as
  3  select * from dba_objects;
Table created.
SQL> set serveroutput on
SQL> exec hao_show_space('HAOCOMPRESS');
##################################################
--------hao_show_space kit created by Hao---------
##################################################
MSSM tablespace:
The segment space usage for TABLE "HAOZHU_USER.HAOCOMPRESS"
##################################################
UNUSED BLOCKS...........................1
UNUSED Bytes............................8192
------------------------HWM------------------------
Free Blocks.............................0
Used Blocks.............................63
##################################################
Total Blocks............................64
Total Bytes.............................524288
##################################################
Last Used Ext FileId....................4
Last Used Ext BlockId...................8248
Last Used Block.........................7
PL/SQL procedure successfully completed.
SQL> exec hao_show_space('HAONOCOMPRESS');
##################################################
--------hao_show_space kit created by Hao---------
##################################################
MSSM tablespace:
The segment space usage for TABLE "HAOZHU_USER.HAONOCOMPRESS"
##################################################
UNUSED BLOCKS...........................84
UNUSED Bytes............................688128
------------------------HWM------------------------
Free Blocks.............................0
Used Blocks.............................172
##################################################
Total Blocks............................256
Total Bytes.............................2097152
##################################################
Last Used Ext FileId....................4
Last Used Ext BlockId...................8448
Last Used Block.........................44
PL/SQL procedure successfully completed.
set timing on
set serveroutput on
exec runStats_pkg.rs_start;
insert into HAOCOMPRESS select * from HAOCOMPRESS;
commit;
exec runStats_pkg.rs_middle;
insert into HAONOCOMPRESS select * from HAONOCOMPRESS;
commit;
exec runStats_pkg.rs_stop(100);
Run1 ran in 75 hsecs
Run2 ran in 19 hsecs
run 1 ran in 394.74% of the time
Name                               Run1       Run2       Diff
STAT...session logical reads       2,425    1,478       -947
STAT...HSC OLTP Space Saving    752,629          0 -752,629
STAT...CPU used by this sessio       65       39       -26
STAT...DB time                         85       45       -40
STAT...redo size                4,554,932 1,410,592  -3,144,340
从insert的性能上来看，LIO增加了两倍，CPU增加了两倍，redo更是增加了2倍以上。
这些overhead应该是Block由于不断到达PCTFREE而引起不断的compress。

7.update performance
set timing on
set serveroutput on
exec runStats_pkg.rs_start;
update HAOCOMPRESS set object_name=to_char(rownum);
commit;
exec runStats_pkg.rs_middle;
update HAONOCOMPRESS set object_name=to_char(rownum);
commit;
exec runStats_pkg.rs_stop(100);
Run1 ran in 507 hsecs
Run2 ran in 247 hsecs
run 1 ran in 205.26% of the time
Name                               Run1       Run2       Diff
STAT...session logical reads    122,627    57,341    -65,286
STAT...HSC OLTP Space Saving    687,461          0 -687,461
STAT...CPU used by this sessio       408       180       -228
STAT...DB time                      510       246       -264
STAT...redo size             42,392,660  24,231,484 -18,161,176
从update的性能上来看，compressed table用了蛮长的时间，LIO和CPU用了两倍以上。
Redo还是保持着2倍左右的overhead。
8.select performance
set timing on
set serveroutput on
set autotrace trace exp stat
exec runStats_pkg.rs_start;
select * from HAOCOMPRESS;
exec runStats_pkg.rs_middle;
select * from HAONOCOMPRESS;
exec runStats_pkg.rs_stop(1);

Run1 ran in 319 hsecs
Run2 ran in 338 hsecs
run 1 ran in 94.38% of the time
Name                               Run1       Run2       Diff
STAT...session logical reads       4,025    4,570       545
STAT...CPU used by this sessio       69       62       -7
STAT...DB time                         86       101       15
从select查询的性能上看，查询的LIO要更少，这是显然的，因为少了很多的blocks。
CPU跟不compressed的table相比不相上下，这是非常不错的，这表明了对于以查询为主的表来说，在CPU overhead基本不变的情况下，会节省更多的IO。

<从宏观上分析>
宏观上主要看看OLTP compressed table和传统老的compressed table的空间利用情况的比较。
create table newcompress compress for oltp as select * from dba_objects;
create table oldcompress compress as select * from dba_objects;
create table notcompress  as select * from dba_objects;
SQL>  select table_name,COMPRESS_FOR from dba_Tables where table_name in ('NEWCOMPRESS','OLDCOMPRESS','NOTCOMPRESS');
TABLE_NAME                   COMPRESS_FOR
------------------------------ ------------
NOTCOMPRESS
OLDCOMPRESS                   BASIC
NEWCOMPRESS                   OLTP


SQL> select SEGMENT_NAME,sum(BYTES)/1024 KB from dba_extents
  2  where SEGMENT_NAME in ('NEWCOMPRESS','OLDCOMPRESS','NOTCOMPRESS')
  3  group by SEGMENT_NAME;

SEGMENT_NAME                KB
-------------------- ----------
OLDCOMPRESS                512
NEWCOMPRESS                512
NOTCOMPRESS             2048
两种压缩方式在最开始的时候差不多大。

SQL> update NEWCOMPRESS set object_name=to_char(rownum);
SQL> update OLDCOMPRESS set object_name=to_char(rownum);
SQL> update NOTCOMPRESS set object_name=to_char(rownum);

SQL> select SEGMENT_NAME,sum(BYTES)/1024 KB from dba_extents
  2  where SEGMENT_NAME in ('NEWCOMPRESS','OLDCOMPRESS','NOTCOMPRESS')
  3  group by SEGMENT_NAME;

SEGMENT_NAME                KB
-------------------- ----------
OLDCOMPRESS                768
NEWCOMPRESS                640
NOTCOMPRESS             2048
在大量更新后，我们发现，传统的compressed table逐渐丢失了自己compress的特性，因为新更新的行很有可能不在原来的block里，这样就导致不能引用原来block里的signal。这应该是传统compressed table的通病了吧。
而OLTP compressed table却依然保持良好的压缩性能。赞。

SQL> drop table OLDCOMPRESS;
SQL> drop table NEWCOMPRESS;
SQL> drop table NOTCOMPRESS;

create table newcompress compress for oltp as select * from dba_objects order by object_name;
create table oldcompress compress as select * from dba_objects order by object_name;
create table notcompress  as select * from dba_objects order by object_name;

SQL> select SEGMENT_NAME,sum(BYTES)/1024 KB from dba_extents
  2  where SEGMENT_NAME in ('NEWCOMPRESS','OLDCOMPRESS','NOTCOMPRESS')
  3  group by SEGMENT_NAME;
SEGMENT_NAME                KB
-------------------- ----------
OLDCOMPRESS                576
NEWCOMPRESS                640
NOTCOMPRESS             2048
我们发现，如果将表里的数据order by一把，来的compressed table拥有更好的压缩比。
为什么呢？原来的compressed table可以对每一行新进来的时候做压缩。
而OLTP compressed table当他某个block达到PCTFREE时就需要压缩，这样本来排好序的数据就insert到下一个block中了。当第一个block压缩完毕迎接新数据的时候，迎接的新数据却变成了非常后面的数据了，无法引用当前block的signal。说简单一点，这应该是不停的block加入和退出freelist，导致本来排好序的数据插入了乱序的block中。（当然，这只是我的猜测，欢迎辩驳）
create index NEWCOMPRESSIDX on NEWCOMPRESS(object_name);
create index OLDCOMPRESSIDX on OLDCOMPRESS(object_name);
create index NOTCOMPRESSIDX on NOTCOMPRESS(object_name);
SQL> select SEGMENT_NAME,sum(BYTES)/1024 KB from dba_extents
  2  where SEGMENT_NAME in ('NEWCOMPRESSIDX','OLDCOMPRESSIDX','NOTCOMPRESSIDX')
  3  group by SEGMENT_NAME;
SEGMENT_NAME                KB
-------------------- ----------
NEWCOMPRESSIDX             512
NOTCOMPRESSIDX             512
OLDCOMPRESSIDX             512
最后，非常无聊的建立索引，得出的结论是，索引还是正常的，跟表的压缩与否没有直接联系。

   --2009 10 16 Hao写于office