DB2记一次表压缩的测试
Posted shengqin105
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了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: 4 Object 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: 325 Tablespace: 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 |
通过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
----------------------------------------记一次db2 备份恢复过程中遇到的用户权限问题