db2 v9.5数据压缩功能初试

在做数据压缩之前我先记录了下面两个值:

$db2 list tablespaces show detail
这里面得到某个tablespace已经used的pages总数

$time db2 "select count(*) from MYSCHEMA.TABLE"
记录下对一个大表的table scan要多长时间

然后是执行下面脚本开始设置数据压缩并进行一次实际的压缩，也就是做一次reorg

#!/bin/ksh
db2 connect to DB1
for i in TABLE TABLE1 TABLE2 TABLE3
do
db2 set current schema MYSCHEMA
db2 "alter table $i compress yes"
db2 "alter table $i data capture none"
time db2 "reorg table $i resetdictionary"
db2 "inspect rowcompestimate table name $i schema MYSCHEMA results keep $i.bin"
db2inspf /home/DB1insance/sqllib/db2dump/$i.bin $i.log
db2 "reorg table $i"
done
exit

$i.log里面的内容如下：
    Table phase start (ID Signed: 4, Unsigned: 4; Tablespace ID: 4) : KABPIW.HAEDC_0707
    
      Data phase start. Object: 4  Tablespace: 4
      Row compression estimate results:
      Percentage of pages saved from compression: 66
      Percentage of bytes saved from compression: 66
      Compression dictionary size: 43136 bytes.
      Expansion dictionary size: 32768 bytes.
      Data phase end.
    Table phase end.
这里可以看到执行压缩后能够省出多少空间

压缩完后可以验证一下节省的空间和做table scan能否节省时间
$db2 list tablespaces show detail

这里计算压缩前后pages的变化

$time db2 "select count(*) from MYSCHEMA.TABLE"
这里看到节省的时间与压缩比是成正比的，做table scan的时间不到原来的1/3, 压缩后的used pages是原来的1/3左右，另外一个tablespace压缩了1/2左右，这个由表的特性决定.

因为数据库在做table scan的时候瓶颈在I/O上面，因而做完数据压缩后存在container上面的page数变少了，所以做table scan对I/O的操作也相应减少，因此可以节约时间，这里CPU的loading会比原先稍微多一点，只要系统上CPU loading不是非常重，做完数据压缩对DB的性能还是有很大提高的。

这里还要说现在DB2数据压缩的缺点，
那就是它还是要基于数据字典的，而这个字典并不能动态的更新，每次做数据压缩时必须要reset dictionary 然后做offline的 db2 reorg 即在做reorg时 table是不可以访问的

这对于我们MES系统这种OLTP的数据库并不是一个很好的选择，因为我们不可能把生产系统停下来做offline的reorg, 实际上我们是每次岁修的时候对数据库做db2 reorg的。

但它对于数据仓库这种类型的应用还是会有非常大的提高，因为数据仓库的数据量一般比较大，而更新相对比较少，select比较多，对照上面我做table scan时间会减少，可见db2 v9.5可以提供数据仓库的性能并且减少对存储的大量需求。这种数据压缩技术据说是将来的数据库技术方向，以牺牲CPU性能来换取更少的I/O和存储空间...