DB2记一次表压缩的测试

丈夫欲遂平生志,一载寒窗一举汤。这篇文章主要讲述DB2记一次表压缩的测试相关的知识,希望能为你提供帮助。
前言最近在做数据库的升级迁移,约有40多个DB,但在申请存储的时候因为资源不足所以需要各种空间腾挪,回头看一下现有的DB消耗的数据量巨大,数据问题总量约100TB,按日立的HDS存储算1TB约1w,妥妥的都是钱的味道。因为应用无休止的外扩,申请存储是日常运维的主要事项之一,很早以前就想将DB2的表压缩机制给用起来,按常规说法,表压缩的好处很多,但唯一的劣势是对CPU的消耗,而我机器的CPU基本是高配,平时使用率极低,我觉得目前条件成熟,可以尝试一下。
现拿一张表做一轮基本的测试。


1.查看原始状态先对指定压缩的表进行收集统计信息,以确认信息准确;

db2 "runstats on table dcs.s_sr_bak"

下表的表空间类型为32K,执行以下语句查看表的容量统计信息
select
SUBSTR(t.TABSCHEMA,1,15) TABSCHEMA,
SUBSTR(t.TABNAME,1,30) TABNAME,
DATA_OBJECT_P_SIZE,--数据空间/MB
INDEX_OBJECT_P_SIZE,-- 索引空间/MB
a.COMPRESSION,--N为不压缩
a.CARD --行数
--LONG_OBJECT_P_SIZE,
--LOB_OBJECT_P_SIZE,
--XML_OBJECT_P_SIZE
from SYSIBMADM.ADMINTABINFO t
left join SYSCAT.TABLES a
on t.TABSCHEMA = a.TABSCHEMA and t.TABNAME = a.TABNAME
where t.TABSCHEMA=DCS and t.TABNAME = S_SR

查询结果为以下,85GB表数据+37GB的索引。
TABSCHEMA
TABNAME
DATA_OBJECT_P_SIZE
INDEX_OBJECT_P_SIZE
COMPRESSION
CARD
DCS
S_SR_BAK
85044096
3716096
N
91387950

2.对表进行重组本步骤不是必须,纯粹测试。对表进行reorg,以确保清理碎片,使用测试效果更加准确(80GB的表大概reorg了12分钟)
db2 "reorg table dcs.s_sr_bak keepdictionary"

重组完成再跑一次runstats,查询admintableinfo的信息如下:
TABSCHEMA
TABNAME
DATA_OBJECT_P_SIZE
INDEX_OBJECT_P_SIZE
COMPRESSION
CARD
DCS
S_SR_BAK
85044096
3716096
N
91387950
*没什么变化,主要此表是我新建的,没啥太多的碎片。


3.压缩前的性能测试使用db2batch,将sql写入testsql.sql中,以下测试SQL并不算十分严谨。
select count(*) from dcs.s_sr_bak;
select sum(count) from
(select dealer_code,count(*) count from dcs.s_sr_bak group by dealer_code);

执行批命令:
db2batch -d ndcs -f testsql.sql -z test_result1.log

生成结果报告如下:
* Timestamp: Mon May 02 2022 13:06:35 CST
---------------------------------------------

* SQL Statement Number 1:

select count(*) from dcs.s_sr_bak;

1
-----------
91387950

* 1 row(s) fetched, 1 row(s) output.

* Elapsed Time is:4.150403 seconds

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

* SQL Statement Number 2:

select sum(count) from
(
select dealer_code,count(*) count from dcs.s_sr_bak group by dealer_code
);

1
-----------
91387950

* 1 row(s) fetched, 1 row(s) output.

* Elapsed Time is:57.839431 seconds



4.压缩评估使用以下命令对表压缩进行预评估:
db2 inspect rowcompestimate table name S_SR_BAK schema DCS results keep compress_info.log

*但很奇怪,此命令生成的文件是在db2dump的目录下的
cd到上述文件的目录下,使用以下命令解析报告文件:
db2inspf compress_info.log compress_info_report.log

打开解析后的文件的内容为以下:
DATABASE: NDCS
VERSION : SQL11057
2022-05-02-13.24.58.126824


Action: ROWCOMPESTIMATE TABLE
Schema name: DCS
Table name: S_SR_BAK
Tablespace ID: 4Object ID: 325
Result file name: compress_info.log

Table phase start (ID Signed: 325, Unsigned: 325; Tablespace ID: 4) : DCS.S_SR_BAK

Data phase start. Object: 325Tablespace: 4
Row compression estimate results:
Percentage of pages saved from compression: 62
Percentage of bytes saved from compression: 62
Compression dictionary size: 47232 bytes.
Expansion dictionary size: 32768 bytes.
Data phase end.
Table phase end.
Processing has completed. 2022-05-02-13.25.58.370473

上述报告压缩率是62%,有点夸张,试一下最终结果如何。


5.执行压缩
db2 "alter table DCS.S_SR_BAK compress yes"

然后执行reorg及runstats,再次查询表的信息,压缩率在50%:
TABSCHEMA
TABNAME
DATA_OBJECT_P_SIZE
INDEX_OBJECT_P_SIZE
COMPRESSION
AVGROWCOMPRESSIONRATIO
CARD
DCS
S_SR_BAK
20384640
3716096
R
5.004887
91387950
【DB2记一次表压缩的测试】通过db2batch执行测试脚本,执行时间无明显变化:
* Timestamp: Mon May 02 2022 14:06:03 CST
---------------------------------------------

* SQL Statement Number 1:

select count(*) from dcs.s_sr_bak;

1
-----------
91387950

* 1 row(s) fetched, 1 row(s) output.

* Elapsed Time is:2.644267 seconds

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

    推荐阅读