前言
最近在做資料庫的更新遷移,約有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
---------------------------------------------
* 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: 61.608291 seconds