在 DB2 for Linux, Unix, and Windows 中的行压缩的最佳实践

核心提示： 索引 PureXML 是存在单独的对象中的 - XML 数据不能被压缩（除非 INLINE LENGTH 子句被使用并且 XML 数据足够小在一行数据中能容纳） LOBs 是存储在单独的对象中 – LOB 数据不能被压缩 LONGs 也是存储在一个单独的对象中 –

索引

PureXML 是存在单独的对象中的 - XML 数据不能被压缩（除非 INLINE LENGTH 子句被使用并且 XML 数据足够小在一行数据中能容纳）

LOBs 是存储在单独的对象中 – LOB 数据不能被压缩

LONGs 也是存储在一个单独的对象中 – LONG 数据不能被压缩

一张表上的平均未压缩行大小对数据库设计使用大行标识符（RIDs）来说非常重要。普通 RIDs 在一个页上有 256 行的限制。这个页面限制在启用了压缩后很容易达到。 使用大 RIDs 让一张表中允许更多被压缩的行。同样的大 RIDs 也允许表变得更大。

复杂的查询倾向于顺序的操作行。有了行压缩，每个页面可以容纳更多的行。因此在进行了数据压缩的数据库的查询的工负载在访问相同的数据量的时候只需要比以前更少的 I/Os 。对于以离散的形式查询的数据，由于结果集只有很少的行（就像一个 OLTP 系统），压缩的效果就可能并不很好。

行压缩在受到 I/O 限制的环境中运行最佳，这个环境有空闲 CPU 周期并且可以被用来对行执行压缩以及解压。此功能在有复杂 select 查询 DSS 工作负载（I/O 查询大多数是顺序并有规律）下工作得非常好。

执行压缩操作，用户数据在 INSERT 和 DELETE 操作后产生的结果写入日志的记录很少。但是在压缩后一些 UPDATE 日志记录却可能比压缩前要大很多。当一个压缩后的行被更新的时候，就算解压后的记录长度没有变化，压缩后也可能发生变化。一个不同数字符号可能用于表示行更新后的版本。你也可以最小化日志压缩。

评估压缩率

在压缩表数据之前，你可以使用 INSPECT ROWCOMPESTIMATE 实用工具来对每个候选表评估节约存储的好处。当你运行这个实用工具并且只希望评估而并不真正创建压缩字典，这张表不该被允许压缩。也就是说，这张表应该已经在创建时设置或之后更改为 COMPRESS NO（这是创建表时的默认值）。在运行 INSPECT 实用工具之前，表中必须有数据。如果表已经启用了压缩功能，那么运行 INSPECT ROWCOMPESTIMATE 实用工具完成已评估的存储节约并建立一个放置在表中的压缩字典。关于这个创建压缩字典的方法将在后面讨论。