如何通过混合列压缩提高 SAN 和 NAS 性能

作者：Art Licht

如何将 Oracle Database 11g 第 2 版 (11.2.0.3) 的混合列压缩特性用于外部 NAS 和 SAN 存储来降低存储容量需求和提升查询性能。

2012 年 7 月发布

本文所述案例研究介绍如何将 Oracle Database 11g 第 2 版 (11.2.0.3) 的混合列压缩特性用于外部 NAS 和 SAN 存储，评估对外部存储使用混合列压缩时对空间和性能的影响。本文还介绍如何启用混合列压缩特性实现类似的好处。

本案例研究使用的产品是 Oracle Sun ZFS 存储系统和用于 SAN 的 Pillar Axiom 存储系统。重点介绍空间节省以及混合列压缩对查询性能的影响。调查对压缩数据和非压缩数据查询的 I/O 差异进行了分析。

分析表明，混合列压缩特性可以让所需存储空间减少 19 倍，数据库查询性能平均提高 6 倍。

Pillar Axiom 存储系统和 Sun ZFS 存储系统

Oracle Pillar Axiom 600 存储系统可对 I/O 优先级进行动态的集成管理，确保关键应用可以在任何负载条件下发挥最佳性能。它是一个模块化存储平台，基于三个智能硬件组合件 — Pillar Axiom Slammer（存储控制器）、Pillar Axiom Brick（硬盘柜）和 Pillar Axiom Pilot（管理平台）— 和一整套数据管理功能，包括支持 Oracle Database 11g 第 2 版混合列压缩特性。此外，Pillar Axiom 服务质量技术可以根据关键应用的重要性确定数据访问的优先级。

Oracle Sun ZFS 存储系统系列提供企业级 NAS 功能以及一整套数据服务，包括快照、克隆、复制和行业领先的性能分析，以及原生压缩、重复数据删除、Oracle 数据库集成和对混合列压缩特性的支持。

压缩概述

为尽可能提高应用运行效率，已经通过数据库智能闪存缓存、分区和压缩等特性对 Oracle 数据库进行了优化，以减少物理硬盘驱动器 (HDD) I/O。

压缩有多种级别和类型。OLTP 表压缩是 Oracle Database 11g Oracle Advanced Compression 选件的一部分，非常适合压缩频繁更新的数据。混合列压缩非常适合需要保持在线提供访问的历史/存档数据。有关 Oracle Advanced Compression 选件或 OTLP 表压缩的详细信息，请参见“Oracle Database 11g Advanced Compression 选件”。

压缩是减少所需存储容量的理想技术。重复数据删除是减少所需存储容量的另一种方法。重复数据删除对于有大量相同数据的备份很有效，每周运行的完全备份就经常会出现这种情况。重复数据删除可以高效地将完全备份转换成无限增量备份。重复数据删除尚未证明对 OLTP 数据库备份同样有效。

事实证明，重复数据删除对于虚拟桌面（通常是多个副本运行相同的操作系统）的联机存储同样有效。较传统的联机应用领域尚未证明重复数据删除的有效性。这正是 Oracle 数据库压缩的过人之处。

可以用多种方式压缩数据。Oracle 数据库中有多种压缩类型，每种压缩类型又各有变体。OLTP 表压缩可应用于分区、表和表空间级别。混合列压缩通常应用于相应的表或表分区。表 1 列出了一些 Oracle 数据库可以使用的数据库感知压缩技术。

Oracle 数据库感知技术的优点在于它先对数据进行压缩，然后才发送到存储系统，这通常会减少数据移动量、提高性能。此外，因为压缩与 Oracle 数据库完全集成，往往可以直接对压缩数据执行查询。

混合列压缩技术是一种在数据库块中组织数据的新方法。顾名思义，此技术使用行和列方法的组合来存储数据。这种混合方法既可获得列存储的压缩优势，又可避免纯列格式的性能劣势。

当 Oracle 数据库检测到 Pillar Axiom 存储系统或 Sun ZFS 存储系统连接到数据库服务器时，就会启用混合列压缩。Oracle Exadata 存储上的 Oracle 数据库也启用了混合列压缩。支持使用 Oracle 自动存储管理与 Pillar Axiom 存储系统的 FC 和 iSCSI 连接。支持通过 Oracle Database 11g Direct NFS Client 与 Sun ZFS 存储系统的 NFS 连接。

Oracle 自动存储管理是一个集成的高性能数据库文件系统和磁盘管理器，其指导原则是应该由数据库而不是管理员来管理存储。使用 Oracle 自动存储管理，管理员无需直接管理可能数以千计的 Oracle 数据库文件。

Oracle Database 11g Direct NFS Client 是经过优化的客户端，它可以更简单、更快速、更具可扩展性地访问 NAS 存储设备上的 NFS 存储。Direct NFS Client 直接内置在 Oracle Database 内核中。

案例研究

下面几节介绍执行的案例研究、使用的架构以及取得的成果。

压缩节省空间

我们使用零售应用的典型数据创建了表 2 所示的数据库。

该数据库所需的总存储空间为 735 GB。

在 Sun ZFS 存储系统和 Pillar Axiom 存储系统上创建了数据库的多个副本，所以每个数据库拥有完全相同的硬件资源。实际上，Sun ZFS 存储系统上的两个数据库副本位于同一个物理 HDD 上，确保了所有性能差异只是因为混合列压缩。

创建了数据的未压缩版本之后，我们创建了一个 OLTP 表压缩版本。将 OLTP 表压缩应用于相同的数据库表降低了空间要求，如表 3 所示。

该数据库所需的总存储空间为 243 GB，总存储空间要求降低了 3 倍。这种缩减在 Oracle Database 11g Advanced Compression 选件的 OLTP 表压缩中很常见，压缩率通常为 2 到 4 倍。

将 Query High 压缩级别的混合列压缩应用于相同的数据库表降低空间要求的效果如表 4 所示。

该数据库所需的总存储空间为 38 GB，总存储空间要求降低了 19 倍。这种缩减略高于 Query High 压缩的典型值，后者的压缩率通常为 6 到 10 倍。

还可以用存储阵列压缩数据。当存储阵列压缩数据时，应用或数据库并不知道数据已被压缩 — 压缩对应用是透明的。

基于存储阵列的压缩要求将数据解压缩，然后将其传输到服务器。各种存储系统中部署了多种压缩算法。在这个测试中，我们选择了 Sun ZFS 存储系统 LZJB 压缩，因为它占用的 CPU 较少。LZJB 是一种无损压缩算法。它包括对 LZRW1 算法的多项改进，后者是 Lempel-Ziv 系列的压缩算法。

图 1 是来自 Sun ZFS 存储系统的屏幕截图，显示了压缩设置。为了对数据执行查询，数据必须是未压缩的，并传输到数据库服务器。

图 1.配置为 LZJB 的基于 Sun ZFS 存储系统阵列的压缩

该数据库所需的总存储空间为 143 GB。对 OLTP 表压缩压缩的数据库使用 LZJB 时，其大小减至 131 GB，如表 5 所示。

数据库感知的压缩技术（如 Advanced Compression 选件和混合列压缩）允许在存储和服务器之间以原生压缩格式传输数据。数据不仅在磁盘上保持压缩状态，在数据库智能闪存缓存中、网络上、数据库服务器缓冲区缓存中以及 Oracle Recovery Manager (Oracle RMAN) 备份或 Oracle Active Data Guard 日志传送过程中，同样保持压缩状态。

Advanced Compression 选件和混合列压缩是 Oracle Database 企业版特有的。阵列压缩（如 Sun ZFS 存储系统中的 LZJB）支持任何应用环境。

所有压缩技术节省的空间与被压缩的具体数据和数据集的大小有关。这个测试使用了少量零售数据，包括零售交易数据、收银机收据以及零售环境的其他典型数据。在 NAS（Sun ZFS 存储系统）和 SAN（Pillar Axiom 存储系统）环境中，混合列压缩的空间节省均为 19 倍。

作为本案例研究的一部分，我们对每个表使用 OLTP 和 Query High 压缩运行 Oracle Advanced Compression Advisor。在所有实例中，预测的准确率超过 95%。您可以对任何存储类型运行 Oracle Advanced Compression Advisor。更多信息，请参见“运行 Oracle Advanced Compression Advisor”部分。

查询性能

为了评估混合列压缩对查询性能的影响，我们构建了两个不同的环境。一个是 NAS 环境，存储通过 Direct NFS Client 连接到服务器。该环境故意设置得很小，I/O 带宽有限，旨在评估混合列压缩在有限 I/O 环境中的影响。它使用了一个小型的单托盘 Sun ZFS 存储系统，只有1 GbE。

每个数据库位于 Sun ZFS 存储系统上的同一组 HDD 上。所有 HDD 在配置成 RAID-Z1 的同一个 Sun ZFS 存储系统池上条带化。所有数据库都托管到同一台物理服务器上：一个 Intel 四插槽 Nehalem 系统。每个数据库都位于自己的克隆虚拟机 (Oracle VM 3.0) 中，配置参数（DRAM、CPU、SGA 等）相同。服务器通过 1 GbE 连接到 Sun ZFS 存储系统。有关硬件配置的详细信息，请参见附录 A。

为了评估性能优势，我们创建了 6 个查询，如附录 B 所示。相对于计算而言，这些查询的复杂性和 I/O 量各不相同。应该指出的是，可以构建一个超大型的存储系统，如此可以消除 I/O 等待，从而创建一个 CPU 受限的架构。这就需要昂贵的大型系统，配备了很多驱动器、闪存存储，甚至还可能有多个阵列。混合列压缩能够大幅提高存储效率，降低对额外存储和额外阵列的需求。

Sun ZFS 存储系统性能监视软件显示缓存命中率高、磁盘利用率低，这是一个运行良好的存储系统的典型情况。图 2 显示磁盘活动平均利用率低于 10%。

图 2.磁盘活动

图 3 显示缓存命中率相当高（90% 以上），每秒访问次数略高于 1100 次。每秒 1100 次访问等同于略高于千兆位以太网的上限 100 MB/秒。

图 3.缓存命中率

本例中的性能限制因素是千兆位连接性。因此，对未压缩数据的查询受到 I/O 的限制。数据库自动负载信息库 (AWR) 报告的快照显示有大量等待 I/O，如表 6 所示。

然后对 Sun ZFS 存储系统的同样 8 个 7200 RPM 驱动器上存储的混合列压缩压缩的表执行同样的一组查询。表 7 显示了同一时段的数据库 AWR 报告。

消除了 I/O 等待时间。Sun ZFS 存储系统分析显示存储系统收到的 I/O 请求大大减少。对未压缩表进行查询时，系统平均每秒有大约 1100 次 I/O 访问。对混合列压缩数据的查询将 I/O 请求降低至约每秒 375 次。

由于 I/O 减少，平均负载下降，CPU 能够在更短的时间内完成更多工作。图 4 显示每秒缓存访问次数由 1100 多次下降到 375 次。

图 4.每秒缓存访问数

我们在 Sun ZFS 存储系统上运行了三个不同的查询，可以看到相对于所需的处理，其复杂性和 I/O 量各不相同。表 8 显示了三种不同查询的结果。

在所有情况下，对混合列压缩数据的查询都比对未压缩数据执行的查询快。查询速度平均提高 7 倍。

第二个环境是部署了 FC 的高性能环境。配置的 SAN 环境显著提高了 I/O 容量。Pillar Axiom 存储系统有 48 个 FC 15000 RPM 驱动器，而不是 8 个 7200 RPM 驱动器。存储通过 4 Gb FC 连接到服务器。将 FC LUN 传到服务器并导入 Oracle 自动存储管理。SAN 环境的带宽是 NAS 环境的 4 倍（4 Gb 对 1 Gb）。两种磁盘配置均为单奇偶校验 RAID。

表 9 显示了三种查询的结果。

即使是在这种较高 I/O 的环境中，CPU 也是在等待 I/O，如表 10 所示。

在所有情况下，对混合列压缩表的查询比对未压缩数据执行的查询平均快 4.5 倍。同样，我们观察到 I/O 等待消失了。

对未压缩数据的查询导致 CPU 等待 I/O（如 iowait 数据所示），混合列压缩可给查询带来最大的好处，因为可以减少必需的 I/O 量。例如，对未压缩数据执行的查询 5 需要 450 万次物理读取，而对混合列压缩压缩的数据执行同一查询只需 13.7 万次物理读取，如 autotrace 数据所示。查询 5 读取一个表，未压缩时是 35 GB，经混合列压缩 Query High 压缩之后只有 1.08 GB 多一点。相当于表缩小了 32 倍。运行该查询，物理 I/O 由 4503701 下降到 137416，也是减少 32 倍。

示例架构

混合列压缩通常主要用于只查询或历史数据。OLTP 表压缩可以用于交易数据、读/写数据，通常可以节省 2 到 4 倍的空间。混合列压缩通常可以节省 10 到 50 倍的空间。

在此测试环境中，OLTP 表压缩节省了 3 倍的表空间，混合列压缩节省了 19 倍的表空间。每种压缩类型有不同的用例。两种类型合理使用时，可以获得最大的好处。

如图 5 所示，可以使用数据库分区按日期对表进行分段，然后对 2011 和 2012 分区中的交易数据（可存放在任何存储设备上）应用 OLTP 表压缩。然后，您可以对历史数据应用混合列压缩。

图 5.数据库分区对表分段

如果数据库有 50 TB，压缩率与本案例研究中所用类似，仅对历史数据应用混合列压缩可将存储从 50 TB 降至 15 TB。

因为 Oracle RMAN、Oracle Active Data Guard 和数据库智能闪存缓存等 Oracle 数据库特性运行于混合列压缩压缩的数据上，减小表大小还有其他好处。这可以让备份和还原的运行速度更快，因为要传输的数据减少了。

运行 Oracle Advanced Compression Advisor

为了评估在现有环境中使用混合列压缩的有效性，运行作为 Oracle Database 11g 标准部分的 Oracle Advanced Compression Advisor 确定潜在的压缩好处。

混合列压缩有四种不同级别：Query High、Query Low、Archive High 和 Archive Low。这四种级别均可运行 Oracle Advanced Compression Advisor。

有关 Oracle Advanced Compression Advisor 的详细信息，请参见 Oracle Advanced Compression Advisor 网站。

启用混合列压缩

下面几节介绍如何在 Sun ZFS 存储系统和 Axiom Pillar 存储系统上启用 Oracle 数据库的混合列压缩特性。

如何在 Sun ZFS 存储系统上启用混合列压缩

1. 升级到 Oracle Database 11g 2.03 版。
   
   

   参见 support.oracle.com（需要注册）上的 My Oracle Support 说明 10404530。

2. 在 support.oracle.com 上搜索补丁 13041324，然后下载并应用。
3. 在 Oracle 数据库服务器上挂载一个或多个 ZFS 共享。
   
   

   以下是 NFS 挂载的 ZFS 共享的一个 fstab 条目示例。注意，使用 Direct NFS (dNFS) 时，数据库将根据需要设置 rsize 和 wsize 参数。

   <Appliance IP address>:<Appliance share mount point> nfs 
   nfsvers=3,proto=tcp,hard,intr,rsize=<# of bytes>,wsize=<# of bytes>
   

4. 以 oracle 用户身份执行以下操作在 Oracle 数据库服务器上启用 dNFS：
   
   
   1. 切换至 $ORACLE_HOME/lib 目录。
   2. 删除符号链接 libodm11.so：
      
      

      rm -f libodm11.so
      

   3. 新建一个符号链接，指向 dNFS 共享库：
      
      

      ln -s libnfsodm11.so libodm11.so
      

5. 启动数据库。

如何在 Axiom Pillar 存储系统上启用混合列压缩

1. 启动数据库。
2. 将数据库的兼容性属性设置为 11.2.0.3.0：
   
   

   [Oracle @ myhost] $ sqlplus / as sysasm      
   
   SQL> alter system set compatible='11.2.0.3.0' scope=spfile sid='*';  
   SQL> alter diskgroup data_hcc set attribute 'compatible.asm'='11.2.0.3.0';   
   SQL> alter diskgroup data_hcc set attribute 'compatible.rdbms'='11.2.0.3.0';
   

3. 将 storage.type 属性值设置为 AXIOM：
   
   

   SQL> alter diskgroup data_hcc set attribute 'storage.type'='AXIOM';  
   

注：这是一种检验磁盘组是否确实为 Pillar Axiom 存储的方法。如果在非 Pillar Axiom 存储上执行上一命令，将显示类似以下内容的错误消息：

ORA-15287: could not set disk group attribute storage.type due to incompatible disks  
ORA-15285: disk '/dev/mapper/XXXXXXXX' violates disk group attribute storage.type

总结

压缩技术可以节省空间、提高性能，并且可以降低数据存储和管理成本。有两件事需要考虑：节省的空间量和这种空间节省对性能的影响。

在本文所述测试中，基于阵列的压缩能够节省空间，但不能改进查询性能，因为数据必须解压才能传输到数据库。使用数据库感知的混合列压缩，则无需解压数据即可传输。

在这个针对零售数据模式的特定测试中，Oracle Database 11g 第 2 版的混合列压缩特性可以将存储信息所需的容量要求降低 19 倍，同时将查询性能提高近 6 倍。

另请参见

• “Oracle Database 11g 的 Advanced Compression 选件”：http://www.oracle.com/technetwork/database/performance/aco11gr2twp0112-1455545.pdf
• LZRW1 算法：http://en.wikipedia.org/wiki/LZRW
• Lempel-Ziv 系列压缩算法：http://en.wikipedia.org/wiki/LZ77_and_LZ78
• Oracle Advanced Compression Advisor 网站：http://www.oracle.com/technetwork/cn/database/options/compression/compression-advisor-095979-zhs.html

致谢

本文的完成有赖于 Maury Edmonds 的大力协助。他目前是 Oracle 解决方案中心的系统工程师，专门从事虚拟化技术、技术演示开发和客户概念验证支持。他帮助构建了本文研究所需的所有测试环境。

关于作者

Art Licht 是 Oracle 北美解决方案中心的首席架构师。Art 原是 Sun Microsystems 北美存储事业部的一位著名工程师兼首席技术专家，随其并购加入 Oracle。他编写了多个与存储有关的最佳实践和蓝图，并且设计了各种大型异构 SAN。Art 领导团队实施了一些行业最大的数据库和 SAP实现。

附录 A — 硬件配置

附录 B — 查询

Oracle 团队估计，要接近在 Oracle Pillar Axiom 存储系统或 Oracle Sun ZFS 存储系统上实施混合列压缩所实现的性能，将需要更多的第三方硬件。因为有些变数将导致 I/O 等待数据库（例如，网络和 CPU 利用率），因此现在并不能确定所需第三方硬件的数量。

查询 1

select count(distinct(t.trx_nbr))
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li
,DWB_RTL_TRX t
,DWR_SKU_ITEM p
,DWR_ORG_BSNS_UNIT s
where
li.trx_nbr = t.trx_nbr
and li.day_key = t.day_key and li.sku_item_key = p.sku_item_key and t.bsns_unit_key = s.org_bsns_unit_key
and li.actn_cd = 'Sale' 
and t.day_key = 20080905
and p.sku_item_desc = 'Chili Sauce' 
and s.state in ('AZ', 'CA', 'NM', 'TX') 

查询 2

select count (*) from DWB_RTL_SLS_RETRN_LINE_ITEM

查询 3

column c format 999,999,999,999
set echo on
set timing on

select count(trx_nbr) c
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li

查询 4

select to_char(cast(li.end_dt_time_stamp as date), 'YYYYMMDD') ,li.actn_cd
,count(distinct(t.trx_nbr))
from
 DWB_RTL_SLS_RETRN_LINE_ITEM li
,DWB_RTL_TRX t
,DWR_SKU_ITEM p
,DWR_ORG_BSNS_UNIT s
where
-- Joins 
    li.trx_nbr = t.trx_nbr
and li.day_key = t.day_key
and li.sku_item_key = p.sku_item_key
and t.bsns_unit_key = s.org_bsns_unit_key
-- Filters
and t.day_key between 20080905 and 20080907 
and p.sku_item_desc = 'Chili Sauce' 
and s.state in ('AZ', 'CA', 'NM', 'TX') group by  to_char(cast(li.end_dt_time_stamp as date), 
'YYYYMMDD') ,li.actn_cd order by 1, 2

查询 5

select state, count(*)
from dwb_rtl_trx t, dwr_org_bsns_unit b
where t.bsns_unit_key = b.org_bsns_unit_key
group by state

查询 6

select state, count(*), sum(qty)
from dwb_rtl_trx t, dwr_org_bsns_unit b, dwb_rtl_sls_retrn_line_item l
where t.bsns_unit_key = b.org_bsns_unit_key
and l.trx_nbr = t.trx_nbr
and l.day_key = t.day_key
and t.day_key = 20080907
group by state;

要了解所有 Oracle 技术中与系统管理员相关的内容，请在 Facebook 和 Twitter 上关注 OTN Systems。