SHOUG成员 – ORACLE ACS高级顾问罗敏
以下是各种表压缩算法特性的进一步描述：
IT系统数据量与日俱增，对IT系统设计、开发、运维各方面人员都带来了巨大挑战。除在硬件层面不断进行投入和加强之外，在软件层面一个重要的应对策略就是数据压缩技术。但是，以本人的经历，国内Oracle数据库却很少采用数据压缩技术，这是为什么呢？Oracle 11g在数据压缩领域有什么新的发展？各种压缩算法的压缩比如何？压缩对性能到底有什么影响？如何合理运用11g压缩技术和管理压缩数据？
本章就将针对上述问题进行分析和叙述，特别是介绍相关案例和实施细节。
为什么Oracle压缩技术运用不普及？
海量数据的增长和挑战
IT系统数据量与日俱增，甚至呈几何级数增长。以下就是国外相关机构在2010年对VLDB数据库数据量变化的统计和预测：
可见，在以往年代最大的数据库为Teradata，而从2003年之后则是Oracle独占鳌头了。该机构并预测在2008年就将出现PB级数据库，可能现在早就有了，至少本人在2004年就见识过国内380TB规模的数据库了。
导致数据量剧增的原因可能包括如下几方面：
- 数据和应用大集中
数据和应用大集中已成为各行各业IT 系统发展的一大趋势。这种趋势给IT系统带来的挑战是全方位的，首先就是数据规模和访问量的急剧增长，面对海量数据的访问性能、安全性、可管理性、高可用性等需求更是IT系统架构设计、应用开发、运行维护等多方人士共同面对的严峻挑战。
- 安全审计的需要
面对日益增长的安全性和合规性需求，特别是面对各种行业组织和国家有关部门的安全审计需求，例如国外的萨班斯-奥克斯利法案（Sarbanes-Oxley Act），越来越多企业的IT系统被要求保留交易明细，甚至需要构建专门的安全审计系统。本人2012年下半年就为某国有大型银行的安全审计系统提供一定的技术服务，该系统一年数据量就达到200TB，将成为该行有史以来最大的数据库。
- 互联网应用的高速增长
互联网应用持续高速增长，不仅导致传统交易数据量的增长，而且由于Web 2.0应用和各种多媒体应用的推广，使得各种内容管理数据也呈蓬勃发展之势。
为什么不采用Oracle压缩技术？
面对这种海量数据增长所带来的挑战，除了采用更先进服务器和存储设备技术之外，在数据库设计方面应该考虑的一个重要技术就是数据压缩技术，就象我们都经常在自己机器上通过 Winzip、rar等工具对大文件进行压缩一样。但是，我们发现国内基于Oracle的数据库很少使用到Oracle压缩技术，为什么会出现这种局面呢？本人分析的原因如下：
- Oracle压缩技术的局限性
首先，Oracle在11g之前的压缩技术的确存在一定的局限性。Oracle 11g之前只有在批量加载数据，并采用direct path load等技术情况下，才能进行数据压缩，也就是说在数据仓库的ETL等典型场景中才可能使用到压缩技术，而在普通OLTP应用中，Oracle没有提供数据压缩技术。这就大大限制了压缩技术的使用范围。
- 担心性能开销
采用了压缩技术，客户担心在数据写入时需要压缩，在查询数据时又要解压缩，都可能增加额外的CPU开销。这也是导致压缩技术没有普遍使用的重要原因之一。
现在早就是11g时代了，Oracle 11g已经在数据压缩技术方面有了突飞猛进的发展。下面我们就在这个新的平台上与大家共同讨论相关技术和应用前景吧。
11g压缩技术概述
Oracle压缩技术特点和好处
总体而言，Oracle压缩技术具有如下特点和好处：
- 节省大量存储空间
就象我们自己压缩文件所期待的一样，Oracle数据库压缩技术带来的好处，首先就是节省大量存储空间。以下就是Oracle公司内部ERP系统的各个应用系统，在压缩前后的存储空间变化情况：
即平均达到3倍的压缩比。大大节省的存储空间带来的效益是全方位的，不仅是存储设备投入的节省，而且对生产、容灾、测试、开发等环境需求都大大降低。
- 性能不降反升
通常地，一旦采用压缩算法，数据写入时需要压缩，在查询数据时又要解压缩，都可能增加额外的CPU开销，这也是广大客户所担忧的。但压缩之后，将带来I/O访问量的大幅度下降，同时也降低了Oracle缓存（Buffer Cache）的开销。这样一正一负，很多测试表明性能是不降反升了。特别是对需要进行大规模数据处理的应用更是收效显著，例如逻辑和物理备份、统计信息采集等。
另外，后面详细描述的11g新OLTP压缩算法并不是在每个DML语句运行时都进行压缩计算，而是采取一种延迟的批处理方式压缩，这也有效保障了DML操作性能不受影响。
- Oracle可在表空间、表、分区级进行压缩
如果表空间设计缺省压缩算法，则所有存储在该表空间的表都将采用相同的压缩算法，这样将简化表压缩的设计和管理工作。当然，在表一级也可定义更个性化的压缩算法。Oracle还支持在分区级定义不同的压缩算法，以满足不同的数据管理需求。例如针对年代久远、极少访问的历史归档数据，可通过分区方式选择压缩效果更好的算法。
- Oracle压缩技术对应用透明
就象大多数Oracle技术一样，Oracle压缩技术对应用也是透明的。这不仅意味着采用压缩技术之后，所有应用无需改造，而且由于Oracle是在数据块级实施压缩，从操作特性而言，压缩后的数据块与普通数据块并无太多区别，因此数据库绝大部分特性和技术都适合于压缩表，例如各种索引、各种表连接技术、分区技术等。
Oracle多种压缩技术特点分析
Oracle公司最早在9i R2版本就推出了表压缩技术。但这种技术只适合于批量数据加载的场景，例如Direct path SQL*Laoder等操作。Oracle在11g之前一直没有推出针对OLTP应用的大并发量随机DML操作的压缩技术。如上所述，这也大大限制了Oracle压缩技术的应用。
在11g特别11 R2发布之后，Oracle不仅推出了适合OLTP应用的压缩技术，而且还推出了多种混合列压缩（Hybrid Columnar Compress）技术。以下就是Oracle现在所具有的各种压缩技术的总体概述：
| 表压缩算法 | 压缩级别 | CPU开销 | 适用场景 | 备注 |
| Basic Compress | 高 | 小 | 数据仓库 | |
| OLTP compression | 高 | 小 | 联机交易，数据仓库 | |
| Warehouse compression (Hybrid Columnar Compression) | 更高 | 更高 | 数据仓库（Exadata环境） | 压缩级别和CPU开销取决于压缩级别为LOW或HIGH |
| Online archival compression (Hybrid Columnar Compression) | 最高 | 最高 | 归档系统（Exadata环境） | 压缩级别和CPU开销取决于压缩级别为LOW或HIGH |
以下是各种表压缩算法特性的进一步描述：
| 表压缩算法 | CREATE/ALTER TABLE语法 | Direct-Path INSERT | 备注 |
| Basic Compress | COMPRESS[BASIC] | 记录通过基本压缩算法进行压缩 | COMPRESS与 COMPRESS[BASIC]含义相同
未使用Direct-Path INSERT的记录没有压缩 |
| OLTP compression | COMPRESS for OLTP | 记录通过OLTP压缩算法进行压缩 | 未使用Direct-Path INSERT的记录将通过OLTP压缩算法进行压缩 |
| Warehouse compression (Hybrid Columnar Compression) | COMPRESS for QUERY[LOW|HIGH] | 记录通过Warehouse compression算法进行压缩 | 该算法将导致较高的CPU负载
未使用Direct-Path INSERT的记录的压缩比较低 |
| Online archival compression (Hybrid Columnar Compression) | COMPRESS for ARCHIVE[LOW|HIGH] | 记录通过Online archival compression算法进行压缩 | 该算法将导致较高的CPU负载
未使用Direct-Path INSERT的记录的压缩比较低 |
需要特别说明的是，目前基于混合列压缩的Warehouse compression和Online archival compression 压缩算法只适合于Oracle软硬件一体机Exadata环境。例如，以下就是在普通存储上试图使用这两种压缩算法所出现的错误：
SQL> create table emp(id number, name varchar(20)) compress for query; create table emp(id number, name varchar(20)) compress for query * 第 1 行出现错误: ORA-64307: 只有位于 Exadata 存储上的表空间才支持混合柱状压缩 SQL> create table emp(id number, name varchar(20)) compress for archive; create table emp(id number, name varchar(20)) compress for archive * 第 1 行出现错误: ORA-64307: 只有位于 Exadata 存储上的表空间才支持混合柱状压缩
- Basic Compress
该算法就是从9i就推出的最传统压缩算法，其特点是通过Direct path SQL*Laoder、Direct path Insert、并行Insert、CTAS(create table as select…)等操作才能进行压缩，或者通过alter table … move及表在线重定义（Table Redefinination）等操作，将非压缩表以批量方式迁移到压缩表。该算法CPU额外开销较小，主要适合于数据仓库领域。
- OLTP Compress
该算法是11g推出的针对OLTP应用的压缩算法，对各种DML操作都可以进行压缩，由于采用了延迟的批处理方式压缩，因此对CPU开销并不大。该算法既适合于交易系统，也适合于数据仓库系统。
- Warehouse compression (Hybrid Columnar Compression)
该算法采用了11g新的混合列压缩技术(Hybrid Columnar Compression)。与前面的基于记录行的压缩算法不同，Oracle混合列压缩是基于列进行压缩的，其压缩比更高，但针对DML操作的CPU开销更大，因此适合于数据很少发生变更的数据仓库系统。
- Warehouse compression (Hybrid Columnar Compression)
该算法采用了11g新的混合列压缩技术(Hybrid Columnar Compression)。与前面的基于记录行的压缩算法不同，Oracle混合列压缩是基于列进行压缩的，其压缩比更高，但针对DML操作的CPU开销更大，因此适合于数据很少发生变更的数据仓库系统。
- Online archival compression (Hybrid Columnar Compression)
该算法也采用了11g新的混合列压缩技术(Hybrid Columnar Compression)。与Warehouse compression不同的是，其压缩比最高，但CPU开销最大，甚至查询操作性能都会有一定影响。因此该算法适合于数据访问很少的数据归档系统。
同样地，虽然该算法对所有操作都可以进行压缩，但Direct path方式进行的压缩效果更好。
该算法的缺省压缩级别为LOW。若设置成HIGH，压缩比将最高，但对CPU开销最大，对访问性能影响也最大。
表压缩语句举例
相比上述原理，表压缩语句其实非常简单。以下是表压缩短语的语法：
例如，如下语句将sales_history表创建为普通压缩表：
CREATE TABLE sales_history … COMPRESS;
如下语句通过Direct-Path INSERT操作，向sales_history表以压缩形式写数据：
INSERT /*+ APPEND */ INTO sales_history SELECT * FROM sales WHERE cust_id=8890;
COMMIT;
如下语句将orders表创建为OLTP压缩表：
CREATE TABLE orders … COMPRESS FOR OLTP;
如下语句的第一个分区表设计为普通压缩，第二个分区设计为OLTP压缩分区，第三个为非压缩的：
create table ( object_id number(10), object_name varchar2(120) ) partition by range(object_id)( partition p1 values less than (100000) compress basic, partition p2 values less than (200000) compress for oltp, partition p3 values less than (maxvalue) nocompress )
如下语句将sales_history表设计为Warehouse compression 压缩表：
CREATE TABLE sales_history … COMPRESS FOR QUERY;
该表的压缩比将高于普通压缩和OLTP压缩，上述语句缺省级别为HIGH。虽然加载性能略有影响，但对查询性能反而提升。不过，该表的DML操作将受影响。
如下语句将sales_history表设计为Online archival compression压缩表：
CREATE TABLE sales_history … COMPRESS FOR ARCHIVE;
该表的压缩比将最高，适合于数据归档目的，甚至查询操作性能都会受影响。
深入剖析Oracle 压缩算法
对技术着迷的读者一定希望深入了解Oracle各种压缩算法的内部机制，限于篇幅，以下仅简要介绍OLTP压缩和混合列压缩算法大致含义。
OLTP压缩算法
- 基本原理
OLTP压缩算法采取的是批量和延迟进行压缩的思路。以下就是示意图：
上图从左到右进行理解。该算法是在数据块级进行压缩，当往一个空块写数时，Oracle并不进行任何压缩。直到达到PCTFREE上限时，Oracle开始对该数据块内的记录进行压缩。然后，继续写入的记录仍然是非压缩的，直到再一次达到PCTFREE限制。周而复始，完成一个数据块的写入和压缩。
还记得Oracle日志工作原理吗？在客户提交一个DML语句的COMMIT操作之后，Oracle并不是马上将DML操作结果写入硬盘，而只是将DML操作的日志项写入联机日志文件。当DML操作达到一定量，例如当联机日志文件满，切换至下一组日至文件（Log Switch）时，或checkpoint等事件发生时，Oracle才以批量形式将DML操作结果真正写入硬盘。这种工作原理的目的就是降低I/O次数，确保联机交易操作的性能。
Oracle OLTP算法类似于上述日志工作原理，批量和延迟压缩目的就是降低对日常单个DML操作的性能影响。另外，这种工作原理还能有效降低碎片和行连接、行迁移的发生。
- 举例
我们再通过一个具体例子，更进一步地了解OLTP算法。
上图表示当Employee表在最初插入4条记录的情况下，在数据块中是没有压缩的，并顺序存放。当插入第5条记录，假设已经达到了PCTFREE的限制，如PCTFREE设置为10%，则Oracle开始启动OLTP压缩算法，示意图如下：
即在该数据块头部产生一个符号表（Symbol Table），记录重复记录情况。例如，分别以t、u、v、w表示John、Doe、Jane、Smith值，而数据块中记录则通过保存指向该符号表的指针方式，进行压缩存储。如第1条记录“1、John、Doe”表示为“1•t•u”，第2条记录“2、Jane、Doe”表示为“2•v•u”，依此类推。
可见该算法本身其实并不复杂。该算法另外一个特点是，Oracle是在一个数据块内部完成所有压缩和解压缩操作，因此I/O次数并没有发生变化。而其它数据库厂商则可能需要通过另外的表或数据字典来保存压缩数据的符号表（Symbol Table）信息，这样将增加I/O次数，性能会有所下降。
混合列压缩算法
我们以如下daily_sales表为例，来简要描述混合列压缩算法的含义。
| Item_ID | Date | Num_Sold | Shipped_From | Restock |
| 1000 | 01-JUN-11 | 2 | WAREHOUSE1 | Y |
| 1001 | 01-JUN-11 | 0 | WAREHOUSE3 | N |
| 1002 | 01-JUN-11 | 1 | WAREHOUSE3 | N |
| 1003 | 01-JUN-11 | 0 | WAREHOUSE2 | N |
| 1004 | 01-JUN-11 | 2 | WAREHOUSE1 | N |
| 1005 | 01-JUN-11 | 1 | WAREHOUSE2 | N |
可见上表的Date、Shipped_From、Restock等字段存在大量重复值。混合列压缩正是采取列压缩方式进行数据压缩的算法，从而达到更高的压缩效果。同时，该算法是以压缩单元（Compress Unit）格式，将一组记录进行列压缩。因此，该算法就称之为混合列压缩。
以下是上述表的压缩单元示意图：
可见，一个压缩单元可以横跨多个数据块，一个字段的值也可能横跨多个数据块。
事实上，Oracle并没有完全公开该算法细节，仅透露该算法在实现过程中考虑了字段数据类型、字段值分布情况、用户制定的压缩级别等多种要素。
作为用户，我们通过上述原理介绍，已经知道该算法压缩效果的确高于普通压缩和OLTP压缩算法了。另外需要了解到的是，该算法的确不适合并发访问量高的交易系统，因为当某条记录发生变更操作时，Oracle可不是只锁住该记录，而是锁住该记录所在压缩单元中的所有记录！
再次声明，Oracle混合列压缩算法目前只适合于Exadata环境，以及数据变更不多的数据仓库和历史数据归档系统。
一个实际案例的分享
项目背景
为满足国家审计部门的需求，某大型国有银行欲建立集中审计数据平台系统，即将该行数十个交易系统的交易明细数据集中到该系统之中，为内外审计、稽核提供数据依据。该系统涉及2000多张表，1年数据就预计达到150TB。针对如此之大的海量数据库，数据的采集、装载、备份和恢复及对外数据服务都面临在巨大压力。幸亏该系统已经决定部署在Oracle 11g RAC平台，也幸亏Oracle服务部门比较早地介入到该项目建设之中，更幸亏Oracle 11g的压缩算法已经日臻成熟。于是，11g压缩算法的充分运用成为该系统降低存储开销、提高系统处理性能的重要技术保障。
测试数据分析
以下我们对该系统测试期间的表压缩测试数据进行分析。
- 测试目的
该测试案例对UDM_AGR_VPAR和UDM_VPAR_BANCS表，采用BASIC和OLTP技术进行压缩测试，并且与生产系统采用的不压缩方式进行对比，比较各种压缩模式的压缩比及各种压缩模式下的加载和查询应用性能。
- 测试样本数据
| 表名称 | UDM_AGR_VPAR | UDM_VPAR_BANCS |
| 数据库中表行数 | 147246157行 | 95472972行 |
| 数据库中表大小 | 20024 MB | 14664MB |
| 是否分区表 | 是 | 是 |
- 测试结果及分析
| 表名称 | 压缩模式 | 大小 | 压缩倍率 | 加载时间 | 压缩耗时 | 全表查询耗时 |
| UDM_VPAR_BANCS | 非压缩 logging | 14664MB | （无） | 16分钟 | 1分53秒 | |
| UDM_VPAR_BANCS_COMPRESS | BASIC nologging | 5152MB | 2.84 | 21分钟 | 加载时直接压缩 | 1分06秒 |
| UDM_VPAR_BANCS_COMPRESS_OLTP | OLTP
nologging |
5984MB | 2.45 | 1小时1分4秒 | 加载时直接压缩 | 1分35秒 |
上面表格数据以UDM_VPAR_BANCS表为例，该表样本数据为95472972条记录，在不进行压缩情况下加载到数据库，所占空间为14664MB，花费了16分钟，全表查询为1分53秒。
该表在采用传统的BASIC算法情况下，加载到数据库所占空间为5152MB，压缩比为2.84倍，与Oracle官方宣传的3倍压缩比相当。加载时间为21分钟，比不压缩的16分钟下降了23%，但全表扫描时间为1分06秒，提高了近1倍！客户对此结果非常满意，因为不仅空间节约了近3倍，全表扫描为1分06秒，相比不压缩的1分53秒，提高了近1倍。虽然加载时间下降了23%，但该系统的批量加载毕竟是一次性的，而查询操作却是高频度的。
该表在采用11g OLTP算法情况下，表现不尽如人意。具体数据为：加载到数据库所占空间为5984MB，压缩比为2.45倍，比BASIC 算法的2.84略有下降。更糟糕的是加载时间为1小时1分4秒，比不压缩的16分钟下降了3.8倍，而全表扫描时间为1分35秒，相比不压缩的1分53秒，提高幅度也不大。究其原因，还是因为该测试案例为批量数据加载，更适合于BASIC压缩算法，而不适合于针对OLTP应用的OLTP压缩算法。
数据压缩相关技术点
哪些表是压缩表？
欲查询哪些表进行了压缩，可查询如下视图：
SQL> SELECT table_name, compression, compress_for FROM user_tables; TABLE_NAME COMPRESSION COMPRESS_FOR ---------------- ------------ ----------------- T1 DISABLED T2 ENABLED BASIC T3 ENABLED OLTP T4 ENABLED QUERY HIGH T5 ENABLED ARCHIVE LOW
欲查询哪些分区表进行了压缩，可查询如下视图：
SQL> SELECT table_name, partition_name, compression, compress_for FROM user_tab_partitions; TABLE_NAME PARTITION_NAME COMPRESSION COMPRESS_FOR ----------- ---------------- ----------- ---------------SALES Q4_2004 ENABLED ARCHIVE HIGH SALES Q3_2008 ENABLED QUERY HIGH SALES Q4_2008 ENABLED QUERY HIGH SALES Q1_2009 ENABLED OLTP SALES Q2_2009 ENABLED OLTP ...
如何更改压缩算法？
一个表的压缩算法是可以更改的，从而适应于不同数据变化情况。例如，交易明细当前数据可采取OLTP压缩算法，而针对超过6个月极少更改的数据可采取Warehouse压缩算法。
以下语句将表转换为basic压缩表：
SQL> alter table emp move compress basic;
以下语句将表转换为OLTP压缩表：
SQL> alter table emp move compress for oltp;
以下语句一个分区转换为basic压缩分区:
SQL>alter table part_objects move partition p3 compress basic;
以下语句修改一个分区的现有压缩算法，但更改之后的压缩算法只对新记录有效，而不影响现有记录。
SQL>alter table part_objects modify partition p1 compress for oltp;
上述move和modify操作均非在线操作，即在进行这些操作时，这些表将不可进行DML操作。欲在线进行压缩算法变更操作，则需要采用表在线重定义技术。限于篇幅，不赘述。请参考Oracle相关联机文档。
哪些记录是压缩记录？
由于表的压缩算法可更改，这样一个表中的记录可以是非压缩或采取不同压缩算法的。欲查询不同记录的压缩情况，可通过记录的ROWID值进行如下查询：
SELECT DECODE(DBMS_COMPRESSION.GET_COMPRESSION_TYPE( ownname => 'HR', tabname => 'EMPLOYEES', row_id => 'AAAVEIAAGAAAABTAAD'), 1, 'No Compression', 2, 'Basic or OLTP Compression', 4, 'Hybrid Columnar Compression for Query High', 8, 'Hybrid Columnar Compression for Query Low', 16, 'Hybrid Columnar Compression for Archive High', 32, 'Hybrid Columnar Compression for Archive Low', 'Unknown Compression Type') compression_type FROM DUAL;
其它技术点
- 压缩表不支持在线shrink操作。
- 表压缩技术不适合于11g新的大对象技术：SecureFiles。因为SecureFiles采用自己的压缩技术。
- 当表采用basic压缩算法之后，表的PCTFREE参数自动设置为0。
- 使用COMPRESS FOR OLTP 或COMPRESS BASIC方式表的字段数量不能超过255个。虽然可以设置成功，但数据实际上是没有压缩的。
- IOT表不支持压缩。
其它压缩技术
不仅数据库表可以进行数据压缩处理，而且在逻辑备份和物理备份、日志传输、大对象等方面均可进行压缩处理。其中大对象压缩技术将在本书后面章节专题讲述，下面将介绍其它压缩技术：
Data Pump中的压缩技术
Oracle 10g在推出Data Pump技术时，就支持元数据（Metadata）压缩。而在11g之后，Data Pump更支持数据本身的压缩。以下是Data Pump的COMPRESSION参数定义值：
COMPRESSION={ALL | DATA_ONLY | [METADATA_ONLY] | NONE}
其中：
- ALL：表示数据和元数据均压缩
- DATA_ONLY：表示只压缩数据
- METADATA_ONLY：表示只压缩元数据
- NONE：没有任何压缩
以下是Data Pump在卸载数据时进行数据和元数据压缩的语句：
PROMPT> expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr_comp.dmp COMPRESSION=ALL
RMAN中的压缩技术
海量数据库的日益增长对数据库物理备份（RMAN）的挑战也越来越高，除在主机、网络、存储、磁带库等硬件方面加大投入之外，在软件方面需要考虑的一个重要技术就是压缩技术。
以下就是Oracle在RMAN技术中所提供的多种压缩技术的概述和对比：
| RMAN压缩级别 | 推出版本 | 特点 |
| LOW | 11.2 | l 最快的压缩算法
l 适合于CPU资源紧张的场景 |
| MEDIUM | 11.1 | l 压缩比中等、CPU资源消耗中等
l 11g之前称之为快速RMAN备份压缩 |
| HIGH | 11.2 | l 最高的压缩比，CPU资源消耗最高
l 适合于网络或I/O为瓶颈，但CPU资源充足的场景 |
以下是在相关语句：
— 设置RMAN压缩级别为MEDIUM
RMAN> configure compression algorithm ‘MEDIUM’;
— 将备份集进行压缩
RMAN> BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
如下语句将磁盘、磁带设备设置为压缩模式，这样，Backup命令中无需再指定压缩短语：
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
如下语句关闭压缩功能：
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET;
RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET;
以下是Oracle公司针对Oracle Application数据库进行压缩备份的测试结果：
可见通过运用10g/11g备份压缩技术，备份数据集被压缩了6倍。
可见通过运用11g备份压缩技术，备份时间不仅比非压缩备份快了不少，而且比10g压缩技术也快了2.5倍。
Data Guard日志传输中的压缩技术
Data Guard作为基于日志传输和同步技术的Oracle容灾技术，日志传输效率将在很大程度上影响Data Guard实施性能和效率。除高带宽、低延迟的网络环境保障之外，通过压缩日志文件，降低网络传输量，也是确保Data Guard性能的重要技术。可惜的是，Oracle 11g之前版本一直没有在日志传输中提供压缩技术，也成了被竞争对手经常被攻击的一个目标。到了11g，Oracle终于在这方面有所作为了。以下就是相关语法，即在相关LOG参数中增加了COMPRESS属性：
LOG_ARCHIVE_DEST_3=’SERVICE=denver SYNC COMPRESSION=ENABLE|[DISABLE]‘
以下是Oracle公司进行的相关测试数据：
其中OLTP应用为国外的JPetStore应用，而批处理应用采用了Direct Load Insert技术。可见，OLTP应用的日志被压缩了2倍，而批处理应用日志被压缩了5倍。
但运用日志压缩技术应考虑如下因素：
- 网络带宽跟不上日志文件产生速度。
- 足够的CPU资源用于压缩算法的计算。
其实，Oracle的日志压缩算法采用的就是gzip技术，具体而言采用的的是zlib压缩引擎的level -1。因此，通过如下语句可估算一个归档日志的压缩比：
— 先压缩一个归档日志
$ gzip -1 <archive redo logfile>.arc
— 显示详细压缩情况，包括压缩比：
$ gzip –list <archive redo logfile.arc>.gz
数据压缩技术运用建议
就像Oracle众多技术的运用一样，数据压缩技术看似简单，其实涉及方案设计、测试、上线和运维管理等诸多方面和阶段的内容。以下就是针对某保险客户的压缩技术运用需求而提供的实施建议，供大家参考：
- 压缩级别设计
首先，确定在tablespace、table，以及partition级实施压缩。
- 压缩算法确定
根据不同表的访问特点以及Oracle不同压缩算法特点，确定具体压缩算法。例如：Basic Compress, OLTP Compress，Warehouse Compress, Online Archival Compress等。
- 压缩测试案例设计
结合压力测试，测试不同压缩算法的空间压缩情况，以及对不同应用（批量加载、OLTP应用、统计分析等）的性能变化情况。
- 压缩算法变更管理
研究和测试表和分区的压缩算法变更技术。例如，move语句和在线重定义等。
- 压缩数据管理
研究和测试压缩表数据字典信息的查询；如何确定具体行的压缩算法；压缩表的增加和删除字段技术；Exp和Imp压缩表，压缩表的RMAN备份恢复等专题。
- 其它压缩技术的运用
研究是否存在LOB字段，并确定是否需要采用SecureFiles压缩技术。同时研究RMAN、Data Pump,甚至Data Guard是否需要采用压缩技术。
这就是Oracle作为企业级软件供应商的技术运用方法、经验和特点：全面性、系统性、专业性。
6.8本章参考资料及进一步读物
本章参考资料及进一步读物：
| 序号 | 资料类别 | 资料名称 | 资料概述 |
| 1. | Oracle 11g R2联机文档 | 《Oracle Administrator’s Guide》 | 请大家重点看该文档第20章“Consider Using Table Compression”小节 |
| 2. | Oracle 11g R2联机文档 | 《Oracle® Database VLDB and Partitioning Guide》 | 请大家重点看第三章“Partitioning and Table Compression”小节，第四章“Using Table Compression with Partitioned Tables”、“Using Key Compression with Partitioned Indexes”等小节。 |
| 3. | Oracle白皮书 | 《 Advanced Compression with Oracle Database 11g》 | Oracle公司介绍11g压缩技术的官方白皮书。链接如下：
http://www.oracle.com/us/products/database/db-advanced-compression-option-1525064.pdf Basic、OLTP、SecureFiles去重和压缩、RMAN压缩、Data Pump压缩、网络传输压缩等均有介绍。 |
| 4. | My Oracle Support | 《Master Note for OLTP Compression (Doc ID 1223705.1)》 | 全面了解11g OLTP压缩算法的文档。 |
| 5. | My Oracle Support | 《11g New Features: Advanced Compression Overview and Advantages (Doc ID 785787.1)》 | 又一篇介绍11g OLTP压缩、SecureFiles压缩、Data Pump压缩、Data Guard网络压缩的文档。 |
| 6. | My Oracle Support | 《All About Advanced Table Compression (Overview, Use, Examples, Restrictions) (Doc ID 882712.1)》 | 更细致介绍11g高级表压缩算法，也就是OLTP压缩算法原理、适应场景、压缩管理的文档。 |
| 7. | My Oracle Support | 《Performance Issue After Enabling Compression (Doc ID 987049.1)》 | 采用压缩技术之后，性能下降了，怎么回事？这并不是普遍现象。该文档道出了一个可能性：11.1.0.7版本的一个Bug: 8287680 |
| 8. | My Oracle Support | 《The OLTP Compression Saves No Space As Expected Using A Row Too Big (Doc ID 1149283.1)》 | 记录太大的情况下，OLTP压缩没起作用，怎么回事？这是正常现象。欲知详情，请看这篇文档。 |
| 9. | My Oracle Support | 《My Data Is Not compressed. (Doc ID 805205.1)》 | 数据为什么没有压缩？这篇文档给出了一个测试场景，以及判断压缩效果的详细脚本。 |
Leave a Reply