数据压缩

可以压缩和解压缩表与分段中的行数据和/或数据库空间中的简单大对象。可以压缩表与表分段中的数据，以减少占用的磁盘空间量。还可以合并表或分段中的可用空间，然后将这些可用空间返还给数据库空间。 压缩数据之前，可估计可以节省的磁盘空间量。

压缩数据、整合数据以及返还可用空间具有以下益处：

• 显著节省磁盘存储空间
• 减少压缩的分段的磁盘使用量
• 显著节省逻辑日志使用量，这样在完成压缩操作后可节省额外空间并可以防止高吞吐量 OLTP 的瓶颈。
• 页面读取更少，因为更多行可以置于一个页面中
• 缓冲池更小，因为更多数据置于同一大小的池中
• I/O 活动减少，因为：
  • 与未压缩行相比，更多压缩行置于一个页面中
  • 压缩行的插入、更新和删除操作的日志记录更小
• 可以压缩按时间分段数据的不常访问的较旧分段，而让频繁访问的更多近期数据处于未压缩的格式
• 可以释放表不再需要的空间
• 备份与复原更快

I/O 绑定表（例如，高速缓存命中率低的表）非常适合压缩。在 OLTP 环境中，压缩 I/O 绑定表可以提高性能。

但是，如果应用程序运行时具有很高的缓冲区高速缓存命中率，并且高性能比空间使用量更重要，那么可能不希望压缩数据，因为压缩可能会稍微降低性能。

查询可以访问压缩表中的数据。

由于与未压缩数据相比，压缩的数据占用更少页面且每页中有更多行，所以查询优化器可能在压缩后选择不同的计划。

如果使用 Enterprise Replication (ER)，那么压缩一个复制服务器上的数据不会影响其他任何复制服务器上的数据。

如果使用高可用性数据复制 (HDR)，源表中的压缩数据在目标表中也处于压缩状态。不能在 HDR 辅助服务器、RS 辅助服务器或 SD 辅助服务器上执行压缩操作，因为 HDR 目标服务器必须具有与源服务器相同的数据和物理布局。

不能使用 onload 和 onunload 实用程序将压缩后的数据从一个数据库移至另一个数据库。在使用 onload 和 onunload 实用程序之前，您必须将压缩表和分段中的数据解压缩。

可使用 OpenAdmin Tool (OAT) 执行与压缩相关的操作，也可通过运行包含带有压缩参数的 SQL 管理 API 命令的 SQL 语句来执行这些操作。 对表或表分段运行 SQL 管理 API create dictionary 命令或初始 compress 命令时，将启用后续数据装入（包含 2000 行或更多行数据）的自动压缩。

在 GBase 8s V8.5 中，必须运行启用压缩的 SQL 管理 API 命令才可以对表或分段进行压缩。 如果启用了压缩，那么必须遵循以下 GBase 8s 还原过程，以更改回没有数据压缩功能的服务器版本，并且必须解压缩或删除任何压缩表和分段。

取代压缩的主要方法是购买更多物理存储器。 取代减少 IO 绑定工作负载内的瓶颈的主要方法是购买更多物理内存，以便扩展缓冲池。