最佳实践之通过深度压缩进行存储优化 - ibm · 自 db2 9.5 版本开始，adc...

IBM® DB2® for Linux®, UNIX®, and Windows®

IBM®

最佳实践之

通过深度压缩进行存

储优化

Thomas Fanghaenel

DB2 for Linux, UNIX, and Windows 内核开发

Bill Minor

信息管理工具

发布日期：2012 年 4 月

通过深度压缩进行存储优化第 2 页（共 35 页）

目录

执行摘要 ................................................................................................................ 4

简介 ........................................................................................................................ 5

值压缩的替代行格式 ............................................................................................ 6

行压缩..................................................................................................................... 7

经典行压缩 ...................................................................................................... 8

自适应行压缩 .................................................................................................. 9

展现压缩设置 .................................................................................................. 10

识别可执行行压缩的候选表格 ............................................................................. 11

启用行压缩的附带效应 ................................................................................. 13

估算行压缩节省的存储空间量 ..................................................................... 14

索引压缩 ................................................................................................................ 18

识别可执行索引压缩的候选索引 .......................................................................... 19

估算索引压缩节省的存储空间量 ................................................................... 20

临时表压缩 ............................................................................................................. 21

应用策略.................................................................................................................. 22

对现有数据执行压缩 ....................................................................................... 22

管理磁盘空间消耗 ...... .................................................................................... 23

验证行压缩，避免常见错误 ........................................................................... 26

验证索引压缩 .................................................................................................... 27

备份映像和日志归档压缩 ...................................................................................... 27

备份压缩 ............................................................................................................ 27

日志归档压缩 ..................................................................................................... 28

最佳实践 ................................................................................................................... 30

结束语 ....................................................................................................................... 31

扩展阅读 ................................................................................................................... 32

编著者 ................................................................................................................. 33

声明 ........................................................................................................................... 34


商标 .................................................................................................................... 35


执行摘要本文档介绍了 DB2 Storage Optimization Feature 与 DB2® for Linux®, UNIX®, and

Windows® 产品搭配使用的最佳实践。本文阐释了如何使此功能成为拓宽大型 OLTP 工

作负载或数据仓库空间意识存储策略的关键驱动因素。

您可以使用 DB2 Storage Optimization Feature 对各类持久存储数据和临时数据进行压

缩。本文就利用这些最佳实践可能实现的优势进行了说明，其中包括以下几点：

• 数据占用的存储空间减少。

• 存储费用降低。

• 数据库性能可能会得到提升，具体情况视您的环境条件而定。


简介

DB2 for Linux, UNIX, and Windows 10.1 版本产品（DB2 10.1 版本）提供了各种途径，

通过多种压缩手段帮助控制、管理和降低数据库对象占用的存储空间。

您可以将压缩技术广泛应用于主用户数据（行数据、XML 数据和索引）、系统生成数

据（临时表）以及管理数据（备份映像和已归档的事务日志）。DB2 Storage

Optimization Feature 还提供了针对主用户和系统生成数据的高级压缩功能。所有

DB2 软件版本中均提供了管理数据压缩工具。

本文对 DB2 10.1 版本中的各种压缩方法进行了介绍，还分别针对每种方法列出了确定是

否采用该方法时值得考虑的要点。同时，本文为您提供了有关识别可进行压缩的候选表和

索引的详细信息。此外还为您阐释了相关最佳实践的详细信息，有助于您在首次采用压缩

技术时最大限度地节省存储空间。


值压缩的替代行格式您可以为用户创建的表选择两种行格式。行格式决定数据存储在磁盘上时行的打包方式。

这两种行格式分别为标准行格式和替代行格式，两者在存储空间需求方面存在显著的差

异。替代行格式可更加紧凑地存储采用可变长度数据类型的列中的 NULL 值、系统默认值

以及零长度值。（可变长度数据类型有 VARCHAR、VARGRAPHIC、LONG

VARCHAR、LONG VARGRAPHIC、BLOB、CLOB、DBCLOB 和 XML）。使用这种

格式的压缩方法称作 NULL 和默认值压缩，或只是称作值压缩。

您可以分别为每个表指定行格式。要创建采用替代行格式的表，请执行以下语句：

CREATE TABLE … VALUE COMPRESSION

要更改表中使用的行格式，请执行以下语句之一：

ALTER TABLE … ACTIVATE VALUE COMPRESSION

ALTER TABLE … DEACTIVATE VALUE COMPRESSION

如果您激活或取消激活某个表的值压缩，则现有的数据保持不变。除非您应用下文“应用

策略”下所列的任何措施，否则各行依然使用当前的行格式。

在标准行格式下，即使实际存储值为 NULL，仍会为固定长度列值分配空间。同样，以可

变长度数据类型存储在列中的零长度值仍然会占用少量空间。但是，在采用替代行格式的

表中，所有列中的 NULL 值及采用可变长度数据类型的列中的零长度值不占用任何空间。

对于采用替代行格式的表，您可以通过对固定长度数字和字符列启用默认值压缩来额外节

省空间。这样磁盘上的行表示将不会具体化系统默认值（数字列为 0，固定长度字符列为

空）。您必须能够在 CREATE TABLE 或 ALTER TABLE … ALTER COLUMN 语句中，

为各列指定 COMPRESS SYSTEM DEFAULT 列选项，来分别压缩各列的系统默认值。

相较于标准行格式，替代行格式还降低了采用可变长度数据类型的列中的所有其他值的存

储开销。然而，存储在固定长度列中的所有非 NULL 值的存储空间消耗量增加。确定所

有受支持数据类型和行格式值字节数的公式位于 CREATE TABLE 语句参考文档。


虽然在绝大多数情况下标准行格式都是不错的选择，但在某些表中，替代行格式能够产

生更加紧凑的存储布局：

• 数据稀疏的表（也就是说，表中包含大量 NULL 值或系统默认值的行）应当采用

替代行格式。不过，每当您将 NULL 值或系统默认值更新为非 NULL 值或非系统

默认值时，行的存储空间需求都会增加。这种更改通常会生成溢出记录，即使表中

不包含可变长度列也是一样，也就是说，当采用标准行格式时，表中的所有行均具

有相同的空间需求。

• 绝大多数列均采用可变长度数据类型的表应使用替代行格式。

对于不具备上述特点的表，使用替代行格式可能会增加存储空间需求。对自身环境进行

测试可能极具价值。

与一些高级压缩功能不同，这两种行格式均不会产生额外的处理开销。因此，您甚至可

以在需要大量 CPU 的工作负载环境中使用值压缩功能。

无论您是否具有 DB2 Storage Optimization Feature 许可，都可以使用替代行格式。这种

灵活性使您能够为每个表选择最紧凑的存储布局，即使您并未计划使用行压缩也是如

此。

如果您计划使用行压缩功能，在绝大多数情况下，请选择较为紧凑的行格式开始减少表占

用的磁盘上空间，尽管效果不太明显，甚至可以忽略不计。这是因为行压缩可以通过标准

行格式十分有效地压缩表中的具体化 NULL 值和系统默认值。

行压缩行压缩自 DB2 for Linux, UNIX, and Windows 9.1 版本产品（DB2 9.1 版本）开始引入。

自此以后每个版本均对行压缩功能进行了大幅改进，并在 DB2 10.1 版本的新一代自适应压

缩功能中达到极致。行压缩要求具备 DB2 Storage Optimization Feature 许可。

通过压缩技术节省存储空间通常意味着减少读取压缩表中的数据的物理 I/O 操作，因为存

储相同数目的行占用的页面数更少。由于压缩技术可在相同数目的页面中打包更多的数据

行，因而缓冲池命中率上升。在许多情况下，I/O 节省和缓冲池利用率提升会增加吞吐量

并加快查询执行时间。


您可以分别对每个表进行行压缩。执行行压缩将会节省绝大多数实用表的存储空间。压缩

率通常为 50% - 80% 或者更高。采用行压缩的表占用的存储空间绝不会超过同一个表的未

压缩版本。

自 DB2 10.1 版本开始，包含以下两种类型的行压缩：

• 经典行压缩，指以下数据采用的压缩技术：

o 自 DB2 9.1 版本开始引入的用户表数据

o 自 DB2 for Linux, UNIX, and Windows 9.7 版本产品（DB2 9.7 版本）开始引

入的 XML 数据和临时数据

• 自适应行压缩，自 DB2 10.1 版本开始引入的全新压缩模式，适用于用户表数据。

自适应行压缩优于经典行压缩，它往往能够达到更好的压缩效果，同时保证压缩率接

近最佳水平所需的数据库维护工作也更少。

经典行压缩经典行压缩以基于字典的压缩算法为基础。每个表对象都对应一个压缩字典。该字典包含

一种在整个表各行中频繁出现的模式映射。这种压缩字典称作“表级压缩字典”。

要执行行压缩，您必须启用压缩表，且数据或 XML 对象必须包含字典。要于创建表时

在 DB2 10.1 版本中对表启用经典行压缩，请执行以下语句：

CREATE TABLE … COMPRESS YES STATIC

要对现有的表启用该压缩模式，请执行以下语句：

ALTER TABLE … COMPRESS YES STATIC

在 DB2 10.1 版本中，上述两种情况均强制执行 COMPRESS YES 语句的 STATIC 选项。在早

期 DB2 版本中，无需进行任何进一步资格限定即可直接使用 COMPRESS YES 语句，如下所

示：

CREATE TABLE … COMPRESS YES

ALTER TABLE … COMPRESS YES

为使经典行压缩在启用压缩功能的表中开始发挥作用，该表必须具有字典。如果您使用的是

DB2 9.1，则必须留意是否具有压缩字典，如有必要，请执行经典表重组或运行 INSPECT

实用程序来创建字典。


随着 DB2 for Linux, UNIX, and Windows 9.5 版本（DB2 9.5 版本）引入自动字典创建

（Automatic Dictionary Creation，ADC）功能，表级字典的构建过程变得更加自动化。

采用 ADC 后，每当启用压缩功能的表的大小超过 2 MB 时，接下来的插入操作都会触发表

级压缩字典的构建过程。但是，不会对现有的行应用任何压缩模式：只有后续插入或更新

才会产生压缩行。

自 DB2 9.5 版本开始，ADC 和经典表重组一直是构建表级压缩字典的两种主要方式。

这两种方式会在各自产生的压缩率方面有所不同。ADC 根据创建字典之时出现的数据

创建压缩字典。如果该表出现大幅增长或显著变化，则构建字典之时将仅包含该表中

的一小部分数据。因此，系统可能仅会对这一小部分数据执行模式检测。但在经典表

重组中，则会对整个表进行扫描，并会运用均匀分布于整个表的记录样例构建字典。

鉴于此，随着时间的推移，通过 ADC 构建的字典的存储空间节约量可能会低于经典表重

组期间构建的字典。同样，久而久之，数据频繁更新的表的表级字典模式有效性可能会下

降，无法再有效压缩这些不断变化的数据，进而导致压缩率下降。在这种情况下，可能需

要定期执行经典表重组，以便始终保持较高的存储空间节约比率。

自适应行压缩自适应压缩在很多情况下不仅能够大幅提高压缩率，而且还能适应不断变化的数据特

征。

在 DB2 10.1 版本中，要创建启用自适应行压缩的表，请执行以下语句之一：

CREATE TABLE … COMPRESS YES ADAPTIVE

CREATE TABLE … COMPRESS YES

要对现有的表启用自适应行压缩，请执行以下语句之一：

ALTER TABLE … COMPRESS YES ADAPTIVE

ALTER TABLE … COMPRESS YES

在 DB2 10.1 版本中，默认行压缩类型为自适应压缩。因此，COMPRESS YES 子句的默认值

为 ADAPTIVE 选项。

当您从 DB2 for Linux, UNIX, and Windows 9.8 版本产品（DB2 9.8 版本）或更早的版本

升级数据库时，启用经典行压缩的现有表将保留其自身压缩设置。如果您希望为这些表启


用自适应行压缩，则必须使用如前所述的 ALTER TABLE 语句之一。

自适应压缩构建于经典行压缩的基础之上，且仍然使用表级压缩字典。表级压缩字典与

页级压缩字典（其中包含单一页面内频繁出现的模式条目）相伴而生。表级字典有助于

在全局范围内消除重复模式，而页级字典则负责处理本地重复模式。

页级字典自动进行维护。当向某个页面填充数据后，数据库管理器会针对该页面中的数

据构建一个页级压缩字典。随着时间的推移，数据库管理器将自动确定何时为数据模式

发生显著变化的页面重建字典。

采用自适应压缩的好处绝不仅限于增加整体压缩节约量。与此同时，自适应压缩还能够确

保压缩率不会像经典行压缩一样随时间推移而降低。在许多实际案例中，压缩率始终接近

最佳状态。因此，通过采用自适应压缩功能，您可以降低表压缩率监控及执行表维护（经

典脱机表重组）的相关成本，以便提高存储利用率。

执行经典表重组仍能实现最佳压缩状态。不过，经典表重组方法对采用自适应行压缩

的表做出的改进不太显著，甚至往往可以忽略不计。

展现压缩设置要确定某个表是否启用行压缩及其采用何种行格式，请查询 SYSCAT.TABLES 视图中

的 COMPRESSION 列。可能的值如下所示：

V. 表使用替代行格式且未进行行压缩。

R. 表使用行压缩且运用标准行格式。

B. 表使用替代行格式且进行行压缩。

N. 表未使用行压缩，但运用标准行格式。

在 DB2 10.1 版本中，要确定对您的表使用哪种行压缩类型，请查询 SYSCAT.TABLES 视

图中的 ROWCOMPMODE 列。可能的值如下所示：

S. 表使用经典行压缩。

A. 表使用自适应行压缩。

Blank. 表未启用行压缩。


在 DB2 9.8 及早期版本中，SYSCAT.TABLES 视图中不包含 ROWCOMPMODE 列。

所有启用行压缩的表均隐式使用经典行压缩。

下面的查询展示了 DB2 10.1 版本中所有用户表的压缩设置：

SELECT SUBSTR(TABSCHEMA, 1, 10) AS TABSCHEMA,

SUBSTR(TABNAME, 1, 10) AS TABNAME,

COMPRESSION, ROWCOMPMODE

FROM SYSCAT.TABLES

WHERE TABSCHEMA NOT LIKE 'SYS%'

样例结果如下所示：

TABSCHEMA TABNAME COMPRESSION ROWCOMPMODE

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

DB2INST1 ACCTCR R S

DB2INST1 BKPF R A

DB2INST1 BSIS B A

DB2INST1 CDCLS N

DB2INST1 CDHDR V

DB2INST1 COSP B S

6 record(s) selected.

在这个示例中，ACCTCR、BKPF、BSIS 和 COSP 表均已启用行压缩。ACCTCR 和 COSP

表采用经典行压缩，BKPF 和 BSIS 表采用自适应行压缩。此外，BSIS 和 COSP 表还采用替

代行格式，而 ACCTCR 和 BKPF 表则采用标准行格式。CDHDR 表使用替代行格式且未

进行行压缩，CDCLS 表使用标准行格式且未进行行压缩。

识别可执行行压缩的候选表格如果您当前未使用行压缩，可能需要检查自身数据库以确定哪些表是可执行压缩的候选

表。数据压缩有助于您首先从现有未压缩表中节省存储空间，并优化未来的存储增长。您

可以在包含大量数据的现有表及预期数据量可能会随时间而大幅增长的表中查找存储“痛

点”。

当然，最大的表显然需要进行压缩，但同时也不要忽视小表。如果您拥有数百或数千个小

表，则也可能会从压缩大量小表的累积效应中受益。“大”和“小”都是相对概念：您的

数据库设计决定包含一百万或数百万行的表格是“大”还是“小”。

下面的示例采用 SQL 管理函数 ADMIN_GET_TAB_INFO，以返回包含针对特定模式的所


有表名称和表数据对象大小的排序列表。要显示当前使用的压缩设置和行压缩模式，通过

SYSCAT.TABLES 视图加入结果集，然后选择 COMPRESSION 和 ROWCOMPMODE

列。

SELECT SUBSTR(T.TABSCHEMA, 1, 10) AS TABSCHEMA,

SUBSTR(T.TABNAME, 1, 10) AS TABNAME,

SUM(TI.DATA_OBJECT_P_SIZE)/1024/1024 AS STORAGESIZE_GB,

T.COMPRESSION AS COMPRESSION,

T.ROWCOMPMODE AS ROWCOMPMODE

FROM TABLE (SYSPROC.ADMIN_GET_TAB_INFO('DB2INST1', '')) TI

JOIN SYSCAT.TABLES T ON T.TABSCHEMA = TI.TABSCHEMA AND

T.TABNAME = TI.TABNAME

GROUP BY T.TABSCHEMA, T.TABNAME, T.COMPRESSION, T.ROWCOMPMODE

ORDER BY STORAGESIZE_GB DESC

此项查询可识别当前数据库中消耗存储空间最多的部分，并为您提供候选表，列出应当处理

的部分。在该示例中，所有表当前均未压缩，除 BSIS 和 CDHDR 表以外的所有表均采用标准

行格式。

TABSCHEMA TABNAME STORAGESIZE_GB COMPRESSION ROWCOMPMODE

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

DB2INST1 ACCTCR 14 N

DB2INST1 BKPF 12 N

DB2INST1 BSIS 12 V

DB2INST1 CDCLS 10 N

DB2INST1 CDHDR 9 V

DB2INST1 COSP 7 N


在许多实际场景中，大部分数据库存储空间均被相对较少的表占用。

小于几百 KB 的小表可能并非经典行压缩的有效候选对象，因为其节约的空间无法抵消数

据压缩字典（约 100 KB）的存储需求。该字典将存储在物理表数据对象中。通常情况下，

考虑对预期将会增长到 2 MB 或以上的表使用经典行压缩。采用自适应压缩时，则无需做

出此类考虑。即使不存在表级字典，也需要构建页级字典。从建表之初就可实现空间节

约，即使对非常小的表也不例外。

在您根据存储空间消耗确定表对象后，请考虑对这些表中的数据执行典型 SQL 活动：

• 只读表是绝佳的行压缩对象。读/写率为 7:3 或以上（读占 70% 或以上，写占

30% 或以下）的表是绝佳的行压缩对象。

• 更新数量有限的表很可能是不错的行压缩对象。


• 经过大量更新的表可能并非行压缩的有效对象。

• 主要通过表扫描（而非索引扫描）进行访问的大表是不错的压缩对象。这通常包含

数据仓库中的大型事实表，其中大量查询执行重聚合。由应用压缩功能实现的 I/O

节约和缓冲池利用率提升很可能会改善这类表的查询性能。

采用经典行压缩好还是自适应行压缩更好，更多的是取决于通过采用上述任一压缩类型可

能实现的实际压缩空间节约量而不是数据访问模式。您需要在该流程的稍后部分决定选择

哪种行压缩模式。

行压缩在特定的 I/O 或内存限制的环境（即工作负载并未在 CPU 上受到堵塞）中性能最

佳。在访问或修改数据行时执行行压缩及扩展数据行，需要消耗额外的 CPU 周期。这部

分开销可通过减少 I/O 操作所提高的效率来进行抵消。行压缩能够极其有效地处理决策支

持工作负载，决策支持工作负载包含执行大规模聚合所需的复杂分析查询，其中行访问绝

大部分具有顺序性，很少随机执行。

启用压缩产生的某些附带效应只有在完成更改后才能进行全面观察。其中可能包括 I/O 节

约量和额外 CPU 开销产生的效应。在环境中的压缩功能生效后，考虑运用测试环境对性

能进行基准测试或评估，然后再对您的生产环境进行改变。

启用行压缩的附带效应在实施行压缩后，由于插入、更新和删除活动而写入到日志记录的用户数据量通常会减

少。但是，某些更新日志记录压缩后可能比未压缩时更大。日志记录变大是因为更新压缩

行时，压缩行映像的大小和内容可能会发生变化，即使只有一小部分行进行更新也会出现

这种情况。

除压缩外，还有其他一些因素也会影响更新操作占用的日志空间量。这些因素包括是否针

对复制（通过 DATA CAPTURE CHANGES）启用更新表，查询是否使用当前提交的语

义，更新后的列位于表中的哪个位置。DB2 10.1 版本信息中心提供了有关列排序及其对更

新日志记录的影响的详细信息。

自 DB2 10.1 版本开始，您可以通过压缩功能降低日志归档占用的空间量。这种功能与是

否启用行压缩无关，也不会影响必须记录的数据量。我们将会在本文档的稍后部分对日志

归档压缩进行介绍。


估算行压缩节省的存储空间量在确定执行压缩的候选表列表后，根据存储空间消耗量和数据访问特征，还需要确定预期

实现的存储空间节约量。您可以在对表启用行压缩之前，估算每个候选表可以节约的空间

量。即使您不具备 DB2 Storage Optimization Feature 许可，也可以估算节约的存储空间

量。

压缩估算机制通常与压缩功能一样也会随时间发展不断演进，其目标在于加速并简化执行

此任务的方式。机制的选择取决于您使用的 DB2 软件版本。同时，DB2 10.1 版本中提供

了旧版本中提供的所有工具和功能。不过，您可能会发现经过改进的 DB2 10.1 版本对应

功能更加易于使用，并且能够更加迅速地提供您所需的数据。

估算在 DB2 10.1 版本中执行行压缩节省的存储空间量

在 DB2 10.1 版本中，估算压缩率的首选方法是使用

ADMIN_GET_TAB_COMPRESS_INFO 管理函数。您可以使用此函数估算特定表、

特定模式中的所有表及数据库中的所有表执行压缩后节省的存储空间量。

该函数可计算经典压缩和自适应压缩的当前压缩节省的存储空间量并进行节省量预测。

下面的示例会针对模式 DB2INST1 中的所有表返回这些值。

SELECT SUBSTR(TABNAME,1,10) AS TABNAME,

PCTPAGESSAVED_CURRENT,

PCTPAGESSAVED_STATIC,

PCTPAGESSAVED_ADAPTIVE

FROM TABLE(SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO('DB2INST1', ''))

表名称和模式名称为可选参数，可以为空或为 NULL 值。如果您未指定表名称，该函数将

会针对特定模式中的所有表估算值；如果您既未指定表名称也未指定模式名称，该函数将

会针对数据库中的所有表估算值。结果列和估算值如下所示：

• PCTPAGESSAVED_CURRENT：当前压缩节省的存储空间量。

• PCTPAGESSAVED_STATIC：通过经典行压缩可以实现的最佳压缩空间

节约量。

• PCTPAGESSAVED_ADAPTIVE：通过自适应行压缩可以实现的最佳压缩空

间节约量。

如果您的模式或数据库包含数百或数千个表，处理时间可能会很长。如果遇到这种情况，

请将您的查询限制为仅针对考虑进行压缩的那些表估算值。


您可以使用前面的查询结果确定是否启用行压缩，以及要选择哪种行压缩模式。例

如，考虑前上一个查询得出的下列结果集：

TABNAME PCTPAGESSAVED_CURRENT PCTPAGESSAVED_STATIC PCTPAGESSAVED_ADAPTIVE

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

ACCTCR 0 68 72

BKPF 0 83 90

BSIS 0 82 90

CDCLS 0 11 17

CDHDR 0 70 73

COSP 0 87 91


在估算压缩值的六个表中，有五个显示出良好的压缩潜力。只有 CDCLS 表压缩潜力

相对较小。压缩节省的存储空间量可能不足以调整抵消在这个特定的表上启用压缩占

用的存储空间量。

计算 PCTPAGESSAVED_STATIC 列和 PCTPAGESSAVED_ADAPTIVE 列之间的差值，有

助于您确定行压缩模式最佳选择。不过，请注意 PCTPAGESSAVED_CURRENT 列值的范

围并非呈线性排列。例如，请思考 ACCTCR 表和 COSP 表。对于 ACCTCR 表，采用经典

行压缩有望节省 68% 的存储空间，采用自适应行压缩有望节省 72% 的存储空间。对于

COSP 表，采用经典行压缩有望节省 87% 的存储空间，采用自适应行压缩有望节省 91% 的

存储空间。虽然两种压缩类型对每个表分别只有 4% 的绝对差值，但自适应行压缩相较于经

典行压缩可实现的相对空间节约量却有所不同。假设未启用压缩之前，各表的大小均为 100

GB。对于 ACCTCR 表，采用经典行压缩的估算大小为 32 GB，采用自适应行压缩的估算

大小为 28 GB，两者之间的差值比例约为 12.5%。然而，COSP 采用经典行压缩的估算大小

为 13 GB，采用自适应行压缩的估算大小为 9 GB，两者之间的差值比例约为 30%。

在上面的示例中，COSP 表适合采用自适应行压缩，但 ACCTCR 表可能不适合采用这种

压缩模式。此外，估算值表明自适应压缩可降低 CDHDR 表的存储大小，但比例仅比经

典行压缩高出 10%。因此，您可能不希望对 CDHDR 表和 ACCTCR 表启用自适应压缩，

除非您预期其数据特征会发生显著改变，或者预计将会插入大量新数据。对于其余的表，

自适应压缩可能是更好的选择，因为这样可额外节省多达 45% 的存储空间。

PCTPAGESSAVED_CURRENT 列的值表明特定表中当前数据的压缩完善程度，前提是假

设您对该表启用了压缩功能。这些测量值与 RUNSTATS 命令对 SYSCAT.TABLES 视图中

的 PCTPAGESSAVED 列计算的值类似，只是 PCTPAGESSAVED_CURRENT 列的测量值

始终保持最新状态。


因此，您不必执行 RUNSTATS 命令来准确计算当前节约的空间量。当您将数据库升级到

DB2 10.1 版本后，PCTPAGESSAVED_CURRENT 列中的值可帮助您决定哪些表需要从

经典行压缩模式转换为自适应行压缩模式。此外，这些值还有助于监控压缩率变化趋

势。

思考下面的示例，如图所示，如果您在早期的 DB2 版本中使用行压缩，则升级到 DB2 10.1

版本后可能会遇到图中的情形。在这种情况下，所有表均启用经典行压缩，上一查询可能

返回如下所示的结果：

TABNAME PCTPAGESSAVED_CURRENT PCTPAGESSAVED_STATIC PCTPAGESSAVED_ADAPTIVE

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

ACCTCR 67 68 72

BKPF 78 83 90

BSIS 80 82 90

CDCLS 0 11 17

CDHDR 69 70 73

COSP 87 87 91


除 CDCLS 表外，所有表均已启用行压缩。某些表（如 BKPF、BSIS 和 CDHDR）显示压

缩率可能会大幅提高，即使仅执行经典表重组也可达到良好的效果。但您可能会强烈希望

对 BKPF、BSIS 和 COSP 表启用自适应行压缩，因为它们将从这种更加有效的压缩功能中

受益匪浅。您或许还希望对 ACCTCR 和 COSP 表启用自适应行压缩，虽然优先级略低，

这是因为从这两种表节约的存储空间量要低于前面几种表。

DB2 10.1 版本中 ADMIN_GET_TAB_COMPRESS_INFO 表函数的处理时间远低于早期

DB2 版本类似管理函数的处理时间。数据管理器如今可执行扫描采样，从而大幅减少做

出准确预测之前必须读取的数据量。在超大表处理方面，您将会经历前所未有的显著飞

跃。

估算在 DB2 9.5 和 9.7 版本中执行行压缩节省的存储空间量 DB2 9.5 和 9.7 版本中也提供类似于 DB2 10.1 版本

ADMIN_GET_TAB_COMPRESS_INFO 函数的管理函数，虽然名称和签名略有不同。

在 DB2 9.7 版本中，该函数称作 ADMIN_GET_TAB_COMPRESS_INFO_V97，而在

DB2 9.5 版本中，其名称为 ADMIN_GET_TAB_COMPRESS_INFO。与采用两个输入参

数的 DB2 10.1 版本函数不同，DB2 9.5 和 9.7 版本函数采用三个参数。第三个参数是执

行模式，为执行压缩估算，您需要输入 ESTIMATE 字符串作为此参数的值。此外，DB2


9.5 和 9.7 版本函数的结果集与 DB2 10.1 版本函数的结果集也有很大的不同。

以前面示例中所举的同一组表为例，在 DB2 9.5 版本中执行压缩估算，如下所

示：

SELECT SUBSTR(TABNAME,1,10) AS TABNAME,

PAGES_SAVED_PERCENT

FROM TABLE(SYSPROC.ADMIN_GET_TAB_COMPRESS_INFO('DB2INST1',

'',

'ESTIMATE'))

TABNAME PAGES_SAVED_PERCENT

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

ACCTCR 68

BKPF 83

BSIS 82

CDCLS 11

CDHDR 70

COSP 87


由于 DB2 9.5 和 9.7 版本仅支持经典行压缩，因而结果集列与 DB2 10.1 版本有所不同。此外，

管理函数的处理时间可能也会比 DB2 10.1 版本明显延长，因为 DB2 9.5 和 9.7 版本需要对每个

表执行全表扫描以估算压缩值。

与 DB2 10.1 版本的管理函数一样，DB2 9.5 和 9.7 版本的管理函数有助于您决定是否启用

行压缩，以及对哪些候选表启用压缩。您还可以使用这些管理函数监控压缩率的变化趋

势，从而帮助您确定何时可能需要执行经典表重组来改进压缩。为确定经典表重组是否可

能会有益，切忌不要比较使用 REPORT 和 ESTIMATE 模式的结果。使用 REPORT 模式不

会返回当前压缩模式节约的空间量。相反，它会在构建字典的同时提供有关压缩模式节约

的空间量的信息，但这可能早已过时。不要对使用上述模式得出的结果进行比较，而是要

首先确保统计数据是最新结果。其次，将管理函数在 ESTIMATE 模式下返回的

PERCENTAGE_PAGES_SAVED 值与同一表的 SYSCAT.TABLES 视图中

PCTPAGESSAVED 列的值进行比较。如果后者明显低于估算的压缩空间节约量，这可能

表明您应当对表进行重组，并通过该流程构建新的表级字典。

估算在 DB2 9.1 版本中执行行压缩节省的存储空间量

DB2 9.1 版本（首个支持行压缩的 DB2 版本）未提供后来版本引入的任何管理函数。


。不过，您可以运行INSPECT 实用程序工具与 ROWCOMPESTIMATE 参数来执行压缩

估算，如下面的示例所示：

INSPECT ROWCOMPESTIMATE

TABLE NAME ACCTCR

SCHEMA DB2INST1

RESULTS acctcr.rowcompestimate.out

在诊断数据目录路径中运行此实用程序会产生 INSPECT 实用程序输出文件。您必须使用

db2inspf 命令行工具格式化此文件，如下面的示例所示：

db2inspf acctcr.rowcompestimate.out acctcr.rowcompestimate.txt

格式化的输出文件包含有关估算的压缩空间节约量的文本信息，如下面的示例所示：

DATABASE: TDB2

VERSION : SQL10010

2011-11-07-18.39.23.555355

Action: ROWCOMPESTIMATE TABLE

Schema name: DB2INST1

Table name: ACCTCR

Tablespace ID: 4 Object ID: 8

Result file name: acctcr.rowcompestimate.out

Table phase start [...]

Data phase start. Object: 8 Tablespace: 4

Row compression estimate results:

Percentage of pages saved from compression: 68

Percentage of bytes saved from compression: 68

Compression dictionary size: 32640 bytes.

Expansion dictionary size: 32768 bytes.

Data phase end.

Table phase end.

Processing has completed. 2011-11-07-18.40.08.349345

INSPECT 实用程序还会将表级字典插入到目标表，只要该表已启用行压缩且不具备表级字典即

可。因此，该实用程序还提供了一种方法，无需执行经典表重组即可在 DB2 9.1 版本中构建压

缩字典。在随后的 DB2 版本中，您不应使用 INSPECT 实用程序构建表级字典，而应使用

ADC 取而代之。

索引压缩如果您使用的是 DB2 9.7 或更高版本且具备 DB2 Storage Optimization Feature 许可，则


可以对索引应用压缩功能。压缩索引可减少叶级页，因而在很多情况下有助于降低索引树

的深度。这样能够减少查找特定键需要访问的索引页，如果采用行压缩还可以提高缓冲池

利用率并减少物理 I/O 操作。在许多实际情况下，索引压缩可以大幅提高查询性能。

您可以分别对每个索引启用索引压缩。当您创建索引时，索引会继承基层表的压缩设置。

也就是说，您在启用经典行压缩或自适应行压缩的表上创建的所有索引也将被压缩。您可

能希望验证自身的数据库构建脚本是否考虑到这层依赖关系。您可以使用 COMPRESS YES

子句创建表，也可以修改这些表以启用行压缩，然后再在上面创建任何索引。

索引压缩融合了三项技术，从而减少磁盘上存储的数据量。通过动态调整索引键数量（而

不是为页面中可以存储的最大键数预留空间）可以节省空间。每个索引项均包含索引键和

RID 列表，通过消除单一页面各键的多余前缀来进行压缩。对于重复的键，则通过采用增

量编码来压缩各列表中的相关 RID。

索引压缩与自适应行压缩一样可完全自动完成，经典行压缩则做不到这一点。随时间推移

仍能保持最佳压缩空间节约量，并且无需为提高压缩率而对索引进行监控和执行潜在的重

组。

识别可执行索引压缩的候选索引最适合实行压缩的索引对象包括以下两种：带有长键的索引（例如，多列索引或字符数

据索引）以及包含大量重复键的索引（例如，基于一个或极少低基数列的索引）。此

外，包含可变长度列（例如，VARCHAR 列）的索引也可能从通过动态索引页面空间

管理提高空间利用率这种方法中受益。

如果主要键列为低基数到中等基数，高基数或惟一列均靠近键列列表的后端，则通常多列

索引压缩效果更好。根据您期望索引支持的查询的特征，在不影响查询性能的情况下即可

对列进行重新排序。用户可能有必要检查大型索引列的顺序和基数，特别是在数据仓库场

景中。在这些情况下，大部分查询会聚合符合条件的行值，而且查询特征通常比在 OLTP

工作负载中更具预测性。

位于单个惟一数字列的索引或将高基数列作为主索引列的惟一多列索引从压缩功能中获益

可能较小。


估算索引压缩节省的存储空间量确定要压缩哪些索引后，估算执行压缩节省的存储空间量的意义甚至比对表更加重大。索

引压缩的相关计算开销低于行压缩开销，节省的存储空间量通常更加直接地对应于整体性

能提升。如果对 OLTP 工作负载中的任意索引进行压缩能够节省大量空间，那么执行压缩

是一个不错的想法。

与行压缩估算函数类似，索引压缩也具有管理函数，用以计算项目节省的存储空间量。

此函数称作 ADMIN_GET_INDEX_COMPRESS_INFO。您可以用它来估算对单个索

引、特定表上的所有索引、特定模式中的所有索引或数据库中的所有索引执行压缩节省

的空间量。您可以通过五个输入参数中的前三个（即对象类型、模式和名称）控制该函

数的执行模式。如果要针对单个索引或特定模式中的所有索引估算空间节约量，请将对

象类型指定为“I”。如果要针对特定表上的所有索引或者某一模式或数据库中的所有表

估算空间节约量，请将对象类型指定为“T”、NULL 或空字符串。您可以根据对象类

型参数的值，使用对象名称和模式参数来确定所需的表或索引。或者，如果要针对一系

列索引估算空间节约量，您也可以将对象名称或模式参数的值保留为 NULL 或空字符

串。

例如，您可以使用以下查询针对所有分区 BKPF 表上的所有索引估算压缩空间节约

量：

SELECT SUBSTR(INDNAME, 1, 20) AS INDNAME,

COMPRESS_ATTR,

PCT_PAGES_SAVED

FROM TABLE(SYSPROC.ADMIN_GET_INDEX_COMPRESS_INFO('T',

'DB2INST1',

'BKPF',

NULL,

NULL))

此项查询的结果集样例如下所示：


INDNAME

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

COMPRESS_ATTR

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

PCT_PAGES_SAVED

--------------- BKPF~0 N 46 BKPF~1 N 57 BKPF~2 N 71 BKPF~3 N 71 BKPF~4 N 45 BKPF~5 N 71 BKPF~6 N 70 BKPF~BUT N 71


图中表明，此表上的绝大多数索引均得到有效压缩，节约了高达 70% 空间。

如果您针对已经压缩的索引调用 ADMIN_GET_INDEX_COMPRESS_INFO 函数，则压缩

节约的空间量反映的是实际节约的空间值而非估算值。另外，您也可以从

SYSCAT.TABLES 目录视图的 PCTPAGESSAVED 列中，获取有关索引压缩生成的当前节

约空间量的信息。RUNSTATS 命令可保持该列的值。

临时表压缩自 DB2 9.7 版本起，如果您具备 DB2 Storage Optimization Feature 许可，则可以对临时

表应用压缩功能。与行压缩和索引压缩不同，您不必对临时表启用压缩功能。压缩会完全

自动执行，且适用于用户定义的表和系统临时表。

用户可在不同情况下使用临时表。系统中包含大量用户定义的全局临时表，它们以两个变

体存在：已创建的全局临时表 (CGTT) 和已声明的全局临时表 (DGTT)。某些实用程序和

维护操作（如表重组和数据再分布）也使用临时表。在查询处理期间，数据库管理器可能

需要使用临时表执行某些操作，并且必须累积一些中间结果，如排序、散列连接或表队

列。

临时表压缩采用的机制与通过 ADC 执行经典行压缩的机制相同，虽然永久表的运行时行

为略有不同。绝大多数临时表（尤其是小表）不会产生任何物理的 I/O。因此，压缩字典

的构建阈值为 100 MB，而不是 2 MB。更高的阈值可确保不压缩通常保持全缓冲状态的小

型临时表，而可能会溢出磁盘的较大临时表具有压缩数据。除避免物理 I/O 外，临时表压

缩还可确保大型临时表更加有效地使用缓冲池，从而帮助进一步避免物理 I/O。


应用策略确定要压缩的一组表和索引后，接下来需要对这些表启用压缩。更改现有表的压缩设置，

填入数据以帮助其减缓增长速度，随后插入的数据将得益于新的压缩设置。如果您的目标

是减少现有数据占用的存储空间，或许也可能是要减少数据库分配的物理空间，那么您必

须对此类数据执行压缩。

您可以应用以下策略，从而帮助对大量现有数据应用压缩功能，释放此类数据当前消耗的

磁盘空间，为文件系统腾出空间。当您首次实施行压缩或索引压缩或者从早期 DB2 版本升

级到 DB2 10.1 版本时，您将会发现此类信息尤其有用。

对现有数据应用压缩对现有数据应用压缩的最直接方法是执行经典表重组。如果您已经更改行压缩或值压缩设

置，请使用 REORG TABLE 命令和 RESETDICTIONARY 参数。如果某些表包含 XML

列，则还需要指定 LONGLOBDATA 子句，以便压缩非内联 XML 文档。如果您仅对索引

压缩设置进行了更改，REORG INDEXES ALL 命令足以压缩索引数据。无需对表数据进

行完全重组。如果您正在从 DB2 9.5 版本升级到 DB2 10.1 版本并且已经启用行压缩，则可

以考虑执行索引重组，而不必对所有表数据执行完全重组。

如果您无法将表转为脱机状态，可以考虑使用 ADMIN_MOVE_TABLE 存储程序，该程序

自 DB2 9.7 版本开始推出。您可以利用此程序将活动表中的数据移动到具有相同名称（存

储位置相同或不同均可）的全新数据表对象中。ADMIN_MOVE_TABLE 程序能够以经典

表重组采用的同一方式对表进行有效重组，但不会产生任何停机时间。移动期间数据仍保

持联机状态。以重组期间的相同质量构建或重建表级字典。为构建或重建表级字典，

ADMIN_MOVE_TABLE 程序需要执行以下步骤：

1. 收集表中所有行的伯努利抽样

2. 从该抽样中构建新的表级压缩字典

3. 先将字典插入目标表，然后再开始复制阶段，这样，当在复制阶段将行插入目标

表时，行才会进行压缩

下面的示例展示了如何以最直接的方式启动表联机移动操作。


CALL

SYSPROC.ADMIN_MOVE_TABLE('DB2INST1','ACCTCR',

'','','','','','','','','MOVE')

您可以使用 ADMIN_MOVE_TABLE_UTIL 程序对表联机移动操作的参数和行为实施细粒

度控制，如确定用于构建字典的抽样大小。尽管如此，即使您以标准的‘MOVE’执行模

式调用该函数，构建的压缩字典也能保证最佳状态。

与经典表重组不同的是，ADMIN_MOVE_TABLE 程序的默认行为是重建字典。由于

仅使用一小部分随机表数据抽样，因而相较于不重建字典，重建字典通常并不会产生

过多的性能开销。

您可能会发现，ADMIN_MOVE_TABLE 程序在从早期 DB2 版本升级数据库时尤其有

用。您可以使用该程序在各表空间之间移动表，同时更改其他参数，如列数据类型。

管理磁盘空间消耗对现有的表应用压缩功能可减少已经分配给这些表的页面数量。然而，应用压缩并不会

对 DMS 或自动存储表空间的磁盘空间消耗产生立竿见影的效果。这些表空间只是具有更

多未使用的空间。

首次实施行压缩或索引压缩时，最好对表空间容器利用率和预计数据增长率进行重新评

估。执行压缩后，您的表空间利用率可能会大幅降低。您的数据库可能需要很长一段时间

才能消耗最初释放的所有的空间。在这种情况下，您可能希望减少容器大小，为其他消费

者腾出更多磁盘空间。

要有效地降低数据库的磁盘占用，必需降低表空间容器大小。决定可多大程度降低表空间

容器大小的主要因素是“高水位线”。高水位线反映分配给表或用作空间映射条目的最高

水平表空间位置。

当您创建表、扩展现有表或执行不使用临时表空间的经典表重组时，高水位线可能会上

升。您可以通过丢弃或截断拥有高水位线处的盘区的表来降低高水位线。然而，丢弃、截

断或重组其他对象不会影响高水位线，只会造成在高水位线下创建更多未用的盘区。只有

在创建新对象或对象增长时，才能重用这部分高水位线下的未使用盘区。只能回收高于高

水位线部分的未用盘区，并将其返回至操作系统。


因此，减少磁盘空间占用的关键在于，降低高水位线并截断表空间容器。本

节的其余部分介绍了执行该项任务的机制。这些机制取决于使用哪种类型的

表空间、使用哪个 DB2 版本创建这些表空间以及当前正在使用哪个 DB2 版

本。

在 DB2 9.7 及更高版本中可回收的存储

您在 DB2 9.7 或更高版本中创建的非临时 DMS 和自动存储表空间支持可回

收的存储。对于这些表空间，数据库管理器可在容器中更改盘区的物理位

置。这种机制称作“盘区移动”，可用于将表空间容器中所有未使用空间合

并到容器的物理末端。完成合并后，高水位线就可降低，表空间容器就可随

即缩小到最小大小。

您可以使用 ALTER TABLESPACE 语句降低高水位线和缩减表空间容器。降

低高水位线的过程涉及盘区移动，因而可能需要花费一些时间。高水位线降

低后，通过将高于高水位线部分的未使用盘区返回至文件系统即可缩小容器

大小。

要确定减少 DMS 或自动存储表空间大小的程度，请使用

MON_GET_TABLESPACE 表函数，如下面的示例所示：

SELECT SUBSTR(TBSP_NAME, 1, 15) AS

TBSP_NAME, TBSP_FREE_PAGES,

TBSP_PAGE_SIZE * TBSP_FREE_PAGES / 1024 /1024

AS TBSP_RECLAIMABLE_MB

FROM TABLE(MON_GET_TABLESPACE('TBSP_USR_D_1', NULL))

下面的样例结果集表明，表空间可减少约 2300 万页，相当于 365 MB 的磁盘占用空间：

TBSP_NAME TBSP_FREE_PAGES TBSP_RECLAIMABLE_MB

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

TBSP_USR_D_1 23369760 365150


您可以使用带 REDUCE MAX 子句的 ALTER TABLESPACE 语句，轻松地将自动存储表空间

缩减为最紧凑的格式，如下面的示例所示：

ALTER TABLESPACE TBSP_USR_D_1 REDUCE MAX

对于 DMS 表空间，降低高水位线和缩小容器的过程只需两步，如下面的两个样例语句所示：


ALTER TABLESPACE TS_DAT_D LOWER HIGH WATER MARK

ALTER TABLESPACE TS_DAT_D REDUCE (ALL CONTAINERS 100 G)

当您将数据库从较旧的 DB2 版本升级到 DB2 9.7 或更高版本时，可以考虑采用以下步骤来获

得可回收存储的收益：

1. 为所有自动存储或 DMS 表空间创建新的表空间。

2. 对这些表启用行压缩或索引压缩。

3. 使用 ADMIN_MOVE_TABLE 程序将您的表从旧表空间移动到新表空间。

在移动这些表之前，您应当启用行压缩和索引压缩，这样才能在移动过程中压缩它们。

在 DB2 9.5 及更低版本中缩小容器

通过 DB2 9.5 及更低版本创建的 DMS 和自动存储表空间不支持盘区移动。因此，最高使用的

盘区将始终保持在高水位线位置。您无法回收分配给低于最高使用盘区的未使用盘区的空

间，除非手动重新排列数据，这样才能释放最高使用盘区。

您可以使用带有 /DHWM 选项的 db2dart 实用程序确定保持高水位线的盘区种类，以及您是

否可以降低高水位线。如果您可以降低高水位线，则可通过使用带有 /LHWM 选项的

db2dart 实用程序列出必要的步骤。

如果表数据对象或 XML 对象保持在高水位线位置，则执行经典表重组可能有助于降低该值。

如果索引对象保持在高水位线位置，重组相关表的索引可能有助于降低该值。如果空 SMP 盘

区保持高水位线，请在 DB2 9.5 或更高版本中使用 ALTER TABLESPACE … REDUCE 语

句，或使用带有 /RHWM 选项的 db2dart 实用程序放弃此 SMP 盘区。

在使用 db2dart 实用程序降低高水位线之前，您必须先停用数据库，受影响的表空间可能会

处于备份暂挂状态，如技术说明1006526 中所述。

如果您无法升级到比 DB2 9.5 更高的版本，当执行经典表重组对表执行压缩时，可以考虑使

用临时表空间。这将有助于避免出现重组需要使用额外盘区（超出了当前高水位线）的情

况。如有可能，请将最大的表置于单独的表空间，然后再尝试执行压缩。

如果在同一 DMS 表空间或自动存储表空间中包含多个表，请首先从最小的表开始执行经典表

重组。这样可确保将高水位线的增长速度降至最低，当重组下一个最大的表时将使用低于高

水位线的全部未用盘区。


验证行压缩，避免常见错误您可以通过查询系统目录揭示各表的压缩设置。在 SYSCAT.TABLES 视图中，

COMPRESSION 和 ROWCOMPMODE 两列包含当前压缩设置的相关信息。

SYSCAT.TABLES 视图中还有其他几个有趣的列，提供了行压缩执行方式的更深入洞察。

RUNSTATS 命令可填充所有这些列。

• 最重要的一项度量位于 PCTPAGESSAVED 列中。此列表明目前通过执行行压缩

在一个表上节约了多少空间。

• 从 PCTROWSCOMPRESSED 列中，您可以确定表中执行压缩的行数。

• AVGCOMPRESSEDROWSIZE 列提供了所有压缩行的平均大小。在大多数实际

场景中，压缩行的百分比应当接近 100%。在这种情况下，压缩行的平均大小将

与 AVGROWSIZE 列中包含的行平均大小相同。

如果某个表中的压缩行的百分比大大低于 100%，这种情况可能是由于下列其中一种

常见问题导致：

• 您的表可能位于常规表空间，压缩可能会导致平均行大小很小。对于常规表空间

中的表，由于每页最多只能承载 255 行，因而有效的最小行大小受到限制。如果

您的平均行大小接近或低于该比例，可以考虑将常规表空间转换为大型表空间。

为此，使用带有 CONVERT TO LARGE 选项的 ALTER TABLESPACE 语句，或

使用 ADMIN_MOVE_TABLE 程序即可将您的表移动到大型表空间。

• 如果您对包含数据的现有表启用行压缩，则当表增长时，系统会通过 ADC 自动构

建表级字典。在执行经典表重组或使用 ADMIN_MOVE_TABLE 函数之前，现有

数据仍将保持未压缩形式。

• 当创建启用了经典行压缩的表并开始填充该表时，当表的大小达到 ADC 阈值 2

MB 时，系统将自动构建表级字典。但是，表的最前面几行仍保持未压缩状

态。如果您的表大小只有几兆，则这个最初未压缩的行集合可能成为存储在表

中的总行数的很大一部分。

如果前面几种情况均不适用，请检查表是否包含随机数据。例如，您的表可能具有大型

CHAR FOR BIT DATA 或内联 LOB 列，其中包含由应用层以某种形式压缩的二进制数

据。在这种情况下，行压缩模式可能无法对您的数据执行进一步的压缩，因此不应对该

表启用行压缩。

当对 MDC 表应用行压缩时，尤其需要多加注意。单元格大小和数据密度都是 MDC


表物理设计过程中需要重点考虑的问题，并且在选择适当的维度方面发挥着重要的作

用。在某些情况下，可选择集群维度，这样单元格使用的页面数目将非常少。

应用行压缩可缩小每个记录的大小，从而缩小单元格的平均大小。如果行压缩导致单元

格平均大小接近或低于单个块的大小，您可能无法发挥出存储空间节约量的最大潜力。这

是因为 MDC 表中的空间分配是在块级别上完成的。部分使用的块会占用磁盘上的一个完

整盘区，但可能包含一大部分空闲空间。

开展物理数据库设计时，如果知道自身将会采用行压缩，请记住，当您对单元格大小进行

预算时将压缩率考虑在内。如果您决定对现有的 MDC 表应用行压缩，请重新验证单元格

大小计算值。您可能发现，有必要粗粒度化 (coarsify) 某些维度或缩小表空间的盘区大小。

验证索引压缩与行压缩一样，您可以通过查询系统目录来检查索引压缩设置。SYSCAT.INDEXES 视图

的 COMPRESSION 列提供了有关各索引的压缩设置信息。

验证是否已对考虑执行压缩的所有索引启用索引压缩。特别留意系统生成的索引，例如，

通过隐式方法为主键和惟一列创建的索引。如果您在未启用行压缩的情况下创建表，随后

使用 ALTER TABLE 语句启用行压缩，那么这些索引将不会被压缩。您必须通过使用

ALTER INDEX 语句为这些索引显式启用索引压缩。

对于那些已经启用压缩的索引，PCTPAGESSAVED 列会提供存储空间节约量相关信

息。RUNSTATS 命令可用于填充此类列。

备份映像和日志归档压缩自 DB2 Universal Database Version 8 开始，您已经能够压缩备份映像。自 DB2 10.1 版

本开始，也可以对日志归档应用压缩功能。无论您是否具备 DB2 Storage Optimization

Feature 许可，都可以使用这些功能。

用于压缩备份映像和归档日志的默认算法与 compress(1) UNIX 实用程序采用的

算法类似。

备份压缩您可以为各备份映像单独启用备份压缩。当执行备份操作时，请指定 COMPRESS 语句，具

体例子如下所示：


BACKUP DATABASE TDB2 to /vol_aux/backups/ COMPRESS

如果您使用行压缩和索引压缩，并且遵循了缩小表空间的容器大小的指导原则，那么数据库

的整体大小可能会大幅缩小。因此，如果禁用行压缩和索引压缩，您的备份映像将自动缩

小，小于其实际大小。与此同时，通过对备份映像应用压缩功能可实现的额外空间节约量可

能会大幅减少。当有大量表采用自适应行压缩时，这一规律尤其适用。但是，备份映像压缩

还能够压缩元数据、LOB、目录表以及无法通过任何其他方式进行压缩的其他数据库对象。

决定是否需要压缩备份映像时，最重要的指标是执行备份时的 CPU 和磁盘利用率。备份压

缩可能会产生大量 CPU 开销。只有在备份过程遭遇 I/O 瓶颈时才应当使用备份压缩。例

如，如果您将备份映像存储在一个为分散在不同物理磁盘的某个卷上或者备份至网络附加

或非本地存储介质上，那么可能会发生这种状况。在这些情况下，整个备份流程的 CPU 利

用率将会增加，但 I/O 开销节约量可以有效缩短备份时间。

如果您将备份存储在 Tivoli Storage Manager (TSM) 软件上，则应使用内置于 TSM 的压缩

和重复数据删除功能。如果您拥有多个最新的备份映像，重复数据删除逻辑可大幅增加存

储空间整体节约量。

如果只有部分表使用行压缩和索引压缩，最好根据压缩设置将表和索引分离到不同的表空

间中。此外，可以考虑在表空间级（而不是数据库级）执行备份。在这种情况下，您可以

平衡压缩设置，仅对包含未经压缩的表和索引的表空间备份执行压缩。

日志归档压缩如果您为数据库配置了日志归档，则可通过数据库配置参数对这些日志归档启用压缩。您

可以单独针对主归档方法、辅助归档方法和相应的归档位置启用或禁用日志归档压缩。日

志归档压缩要求使用数据库管理器处理归档流程，也就是说，您必须将归档方法设置为

DISK、TSM 或 VENDOR。下面的示例展示了在启用压缩的情况下，如何设置主要日志归

档和基于磁盘的日志归档：

UPDATE DB CFG FOR TDB2 USING LOGARCHMETH1 DISK:/vol_aux/archive/tdb2

UPDATE DB CFG FOR TDB2 USING LOGARCHCOMPR1 ON

对于辅助归档方法，您也可以用类似的方式启用压缩。


日志归档压缩在启用后完全自动执行。将日志盘区从活动日志路径移动到归档位置后，

数据库管理器将自动压缩日志盘区。当检索日志文件（可能在 ROLLBACK 和

ROLLFORWARD 命令操作期间发生）时，数据库管理器会在将压缩的日志文件从归档

位置移动到活动日志路径或溢出日志路径时自动扩展这些文件。如果在恢复过程中，数

据库管理器在活动日志路径或溢出日志路径中遇到一个压缩的日志盘区，将会自动扩展

该盘区。例如，如果手动从归档位置将日志盘区检索到活动日志路径或溢出日志路径，

则可能会发生这种状况。

当决定是否要对日志归档启用压缩时，需要考虑的注意事项与应用备份压缩类似。检查归

档位置的可用 I/O 带宽，并查看它是否是归档流程期间的瓶颈。

如果您的日志归档位于非本地卷或未分散在大量磁盘上的卷上，可以考虑启用压缩。此

外，如果您将日志归档至磁盘上的暂存位置，以便随后通过 db2tapemgr 实用程序传输到

磁带上，也可以考虑启用压缩。在这种情况下，压缩有助于缩短将归档日志传输至磁带花

费的时间。

如果您归档至 TSM，可以考虑使用其内置的压缩工具。日志归档的行为与 DB2 10.1 版本

中压缩工具的行为极其类似，因为它们采用了同一种算法。与备份压缩不同的是，一般无

法从重复数据删除功能中获得额外收益。

当您使用行压缩和索引压缩时，写入事务日志的某些数据已经是压缩格式。因此，记录

的数据量要小于您对未经压缩的表执行同样的操作时需要处理的数据量。不过，即使广

泛使用行压缩和索引压缩，事务日志中通常包含足够的元数据和其他未压缩项目，可供

您在几乎任何日志归档上实现重大的存储空间节省。


最佳实践

• 谨慎选择要执行压缩的候选表和索引。

• 先估算压缩率，然后再选择应用哪种行压缩模式。

• 了解并选择对现有的表和索引进行压缩的特定方法。

• 通过使用可回收存储表空间，轻松地将压缩节约的存储空间返回到文件

系统。

• 通过采用统计方法，监控并测量行压缩的有效性。

• 通过采用自适应行压缩模式，缓解表重组需求。

• 通过压缩备份映像和日志归档，控制管理数据占用的存储空间。


结束语运用 DB2 Storage Optimization Feature 提供的压缩技术能够大幅降低当前及未来的存储

空间需求并提高绩效，这种方法对工作负载受 I/O 限制的环境尤其有效。通过搭配使用此

软件与其他管理数据压缩功能，对大型 OLTP 工作负载或数据仓库实施具有空间意识的存

储策略将不再困难。


扩展阅读 • DB2 最佳实践 –

http://www.ibm.com/developerworks/data/bestpractices/db2luw/

• DB2 最佳实践：联机事务处理 (OLTP) 环境的物理数据库设计 –

http://www.ibm.com/developerworks/data/bestpractices/databasedesign/

• DB2 最佳实践：数据库存储 –

http://www.ibm.com/developerworks/data/bestpractices/databasestorage/

• IBM Database Magazine，2007 年第 12 卷第 3 期，分布式 DBA：DB2 深度压缩

(Roger E. Sanders)

• IBM Database Magazine，2008 第 13 卷第 1 期，分布式 DBA：DB2 深度压缩 -

第二部分 (Roger E. Sanders)

• IBM DB2 深度压缩为 SAP 客户带来的运营成本节约优势 –

https://www-304.ibm.com/easyaccess/fileserve?contentid=172719

• DB2 10：多温度数据管理建议 –

http://www.ibm.com/developerworks/data/library/long/dm-

1205multitemp/index.html

• IBM Tivoli Storage Manager 信息中心 –

http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3/index.jsp

http://www.ibm.com/developerworks/data/bestpractices/db2luw/

http://www.ibm.com/developerworks/data/bestpractices/databasedesign/

http://www.ibm.com/developerworks/data/bestpractices/databasestorage/

http://www.ibm.com/developerworks/data/library/long/dm-

http://publib.boulder.ibm.com/infocenter/tsminfo/v6r3/index.jsp


编著者

Serge Boivin

DB2 信息开发部资深作家

Victor Chang

DB2 数据仓库性能 QA 部团队主管

Tom Hart

DB2 开发部软件工程师

Bill Phu

系统优化技术中心软件工程师

Quentin Presley

DB2 开发部软件工程师

Allan Risk

DB2信息开发部资深作家

Sripriya Srinivasan

DB2技术支持部软件工程师


声明本信息是针对在美国提供的产品和服务而开发的。

IBM 可能不会在其他国家/地区提供本文档中所讨论的产品、服务或功能。有关您当前所在区域的产品

和服务信息，请向当地的 IBM 代表咨询。任何对 IBM 产品、程序或服务的引用并非意在明示或暗示只

能使用 IBM 的产品、程序或服务。只要不侵犯 IBM 的知识产权，任何同等功能的产品、程序或服务都

可以替代使用。不过，用户需自行负责对任何非 IBM 产品、程序或服务的操作进行评估和验证。

IBM 可能已经拥有或正在对本文档所述的主题申请专利。提供本文档并不代表向您授予这些专利的任

何许可。您可以通过书面形式将许可咨询寄送至：

IBM Director of Licensing

IBM Corporation North

Castle Drive Armonk,

NY 10504-1785 U.S.A.

本段内容不适用于英国或这些规定与当地法律不一致的任何其他国家/地区：国际商业机器公司按“原

样”提供本出版物，不提供任何明示或暗示的担保，包括但不限于对非侵权性、适销性或特定用途的

适用性的任何担保。某些州不允许在某些交易中对明示或暗示的担保免除责任，因而此声明可能不适

用于您。

在未限制上述免责声明的前提下，对于本出版物中提供的任何信息或建议的准确性、可靠性或适用性

相关的内容，或者使用该信息或遵循此处提供的任何建议可能带来的任何结果，IBM 不提供任何陈述

或担保。本文档中包含的信息尚未提交 IBM 进行任何正式测试，并且均按“原样”分发。使用此信息

或实施本文提供的任何建议或技术时，客户需自行负责根据客户自身的能力进行评估，并将它们集成

至客户的操作环境。虽然 IBM 已在特定条件下对各项目的准确性进行了检查，但不能保证在其他地方

能够获得相同或类似的结果。尝试针对自身环境调整这些技术的任何客户均须自行承担由此带来的风

险。

本文档及其中所包含的信息只能用作与本文档所讨论的 IBM 产品相关的用途。

本信息可能存在技术错误或印刷错误。IBM 将定期对此处的信息进行更改，并将这些更改纳入该出版

物的新版本中。IBM 可能随时对本出版物中所述的产品和/或程序进行改进和/或调整，恕不另行通

知。

本信息对非 IBM 网站的任何引用均仅供参考，不以任何形式用作对这些网站的认可。这些网站的资料

并不属于此 IBM 产品资料，使用这些网站需自行承担风险。

IBM 可能以自身认为合适的任何方式使用或分发您提供的任何信息，并且无需对您承担任何义务。

本文所载的任何性能数据均在受控环境中得出。因此，其他操作环境获得的结果可能会存在显著差

异。一些度量结果可能是在开发级系统上获得的，因而无法保证在一般的可用系统上也能获得同样的

度量结果。此外，一些度量结果可能是通过推断获得的。实际结果可能有所不同。本文档的用户应当

针对自身的特定环境对适用数据进行验证。


有关非 IBM 产品的信息均从这些产品的供应商、他们发布的公告或其他公开可用来源获得。IBM 并未

对这些产品进行测试，因而无法确认有关非 IBM 产品的性能、兼容性或任何其他声明的准确性。关于

非 IBM 产品功能的问题，应向这些产品的供应商进行咨询。

所有关于 IBM 未来方向或意向的声明仅代表 IBM 的发展目标，如有更改或撤销，恕不另行通知。

此信息包含日常业务操作使用的数据和报告示例。为尽可能完整地进行阐述，这些示例纳入了个人、

公司、品牌和产品名称。所有这些名称均为虚构，如与实际企业使用的名称和地址出现任何雷同，纯

属巧合。

版权许可：© Copyright IBM Corporation 2008, 2012. 保留所有权利。

本信息包含源语言形式的样例应用程序，用以阐释各种操作平台上的编程技术。您可以用任何形式复

制、修改和分发这些样例应用程序，并且无需向 IBM 支付任何费用，以便按照编写样例程序的操作平

台应用程序编程接口要求，开发、使用、推广或分发应用程序。这些示例并未在所有条件下进行全面

测试。因此，IBM 无法保证或暗示这些程序的可靠性、可服务性或功能。

商标 IBM、IBM 徽标和 ibm.com 是国际商业机器公司在美国和/或其他国家（地区）的商标或注册商标。

如果上述和其他 IBM 商标词汇在本文中第一次出现时标记了商标符号（® 或 TM），这些符号表示在

本文出版之际，它们是 IBM 在美国或其他国家注册的商标或普通法规定的商标。这些商标也可能是其

他国家/地区的注册商标或普通法规定的商标。有关 IBM 商标的最新列表，可在 Web 上通过访问

www.ibm.com/legal/copytrade.shtml 的“Copyright and trademark information”部分来获取。

Windows 是 Microsoft Corporation 在美国和/或其他国家（地区）的商标。

UNIX 是 The Open Group 在美国和其他国家（地区）的注册商标。

Linux 是 Linus Torvalds i在美国和/或其他国家（地区）的注册商标。

其他公司、产品或服务名称可能是其他公司的商标或服务标志。

http://www.ibm.com/legal/copytrade.shtml

最佳实践之 通过深度压缩进行存 储优化 - ibm · 自 db2 9.5 版本开始，adc...

Documents

最佳实践之通过深度压缩进行存储优化 - ibm · 自 db2 9.5 版本开始，adc...