Oracle11g新特性之：数据压缩技术

随着数据量的不断海量 CPU的不断强劲 双核四核的叫个不停 一种叫做时间换空间的优化技术应该会越来越流行 所以 数据压缩对于今后的数据库来说 应该会从核武器变成常规武器 Oracle从 i开始羞羞答答的引入表级压缩 一直以来都是像中国的核电站一样 宣传的用处大 论实际的贡献就不怎么样了

Oracle g似乎是正儿八经的要推广数据压缩技术了 专门推出了一个叫做Advance Compression的组件 全面支持普通表压缩 非结构化数据压缩（SecureFile数据压缩） Data Pump数据压缩 以及RMAN备份压缩 数据压缩技术从此名正言顺的登上历史舞台 既然是专门做为一个Option推出 Oracle一定是对该特性相当有信心 所以需要单独为该特性购买License

在Oracle i中虽然引入了表压缩 但是有很大的限制 只能对批量装载 *** 作（比如直接路径装载 CTAS等）涉及的数据进行压缩 普通的DML *** 作的数据是无法压缩的 这应该是对于写 *** 作的压缩难题没有解决 一直遗留到Oracle g 总算是解决了关系数据压缩的写性能问题 Oracle的表压缩是针对Block级别的数据压缩 主要技术和Oracle i差不多 还是在Block中引入symbol表 将block中的重复数据在symbol中用一个项表示 Oracle会对block进行批量压缩 而不是每次在block中写入数据时都进行压缩 通过这种方式 可以尽量降低数据压缩对于DML *** 作的性能影响 这样 在block级别应该会引入一个新的参数 用于控制block中未压缩的数据量达到某个标准以后进行压缩 *** 作

SecureFile也是Oracle g新推出的一项特性 用于存储非结构化数据 SecureFile也将支持数据压缩 *** 作 这样对于传统的LOB字段也可以进行压缩 将极大的减少大型数据库的存储空间需求 当然 有得比有失 压缩和解压时 对于CPU的要求也将更高 但是 目前CPU的发展速度明显比IO和存储空间快速的情况下 压缩是大有可为的技术 通过在压缩率和压缩效率方面的不断提升 以后应该为成为各个数据库的标准配置

除了对数据库中的数据进行压缩 Advance Compression Option还将支持备份数据的压缩 做为逻辑备份的Data Pump和物理备份的RMAN工具 都将支持该技术 在Oracle gR 中 Data Pump已经开始支持压缩源数据 Oracle g中则可以直接压缩导出文件 这样导出的时候就可以极大的减少存储空间的需求 在以前版本中 利用WinRAR等 经常可以将几个G的导出文件压缩到几十M Oracle g的白皮书上说压缩率可以达到 % 等软件出来 大家可以好好的测试一把 同样的 Oracle也在 g中开始引入RMAN的压缩技术 但是Oracle g号称采用了更先进的ZLIB要所算法 可以比Oracle g的压缩算法快上 % 空间需求也将减少 %

除了上述的数据压缩技术 Oracle g Advanced Compression Option还将引入另外一种压缩技术 我们知道在Data Guard中 需要将日志从主库传递到备库 如果主库的事务很多 则单位时间内需要传递的日志量将相当可观 如果能将这些日志压缩后在传递 然后在备库解压后应用 将极大的减少对于网络带宽的需求 从而已减少主备库的时间差

另外 Oracle的bitmap一直就是压缩存储的 g中的bitmap对于 i就有比较大的改动 通过一些细节的完善 提供更好的性能和更高的稳定性 也是oracle一贯的风格 对于bitmap在Oracle g中将如何实现 也将是非常值得关注的一个特点

lishixinzhi/Article/program/Oracle/201311/16929

Hybrid Columnar Compressed

首先我们要搞清楚，什么是行压缩，什么叫列压缩。我们熟悉的数据库，如Oracle，MySQL等都是基于行的数据库，就是行的不同字段物理上存放在一起，还有一种是基于列的数据库，就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出：

基于行的数据库，访问一行非常方便，但是由于同一列的数据是分开存放的，如果要针对某一列进行查询时，几乎要扫描整个表才能得到结果。基于行数据库的压缩，称为行压缩。

基于列的数据库，因为同一列的数据物理上放在一起，所以访问一列非常方便，也就是说如果针对某一列进行查询时，不需要扫描整个表，只需要扫描这一列的数据就可以了，但是访问一行的全部字段非常不方便（又是废话）。基于列数据库的压缩，称为列压缩。

Oracle通常说的compress功能（包括11g R2的Advanced compress），都是行压缩，因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table，然后将相同的值放在那里，每行上相同的数据指向symbol table，以此来达到压缩的目的。行压缩的效果通常不好，因为我们知道行与行之间，其实相同的数据并不多。但是列压缩则不同，因为相同列的数据类型相同，很容易达到很好的压缩效果。

行压缩和列压缩都有其优缺点，而Oracle的混合列压缩技术，实际上是融合了列压缩的高压缩比和行数据库的访问特性，将两者的优点结合起来。Oracle提出了CU的概念（compress unit），在一个CU内，是一个基于列的存储方式，采用列压缩，但是一个CU内保存了行的所有字段信息，所以在CU与CU之间，Oracle还是一个基于行的数据库，访问某一行，总是只在一个CU内。每个CU由一些连续的block组成，CU header中记录了每一行的各个列在CU中的分布情况，在混合列压缩模式下，一行通常是跨多个block的。

所以说混合列压缩，结合了列压缩和行访问的特点，即可以提供非常高的压缩率，又很好的保证了基于行类型的访问。

Exadata的另一个重要功能是IO resource management，如果我们在一个Exadata上部署了很多个数据库，可以用它来管理IO资源，这里就不作阐述了。

目前，我还没有了解到在国内有Exadata的应用，而且资料也是比较少的。希望有机会可以真实的测试一下它的性能，我不怀疑他在DSS环境下的表现，但是对于OLTP类型的应用，是否真的象Oracle说的那么强劲，还有待于验证。

---