在做数据压缩之前我先记录了下面两个值:
$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和存储空间...
阅读(2947) | 评论(0) | 转发(0) |
