Oracle压缩黑科技(一)—基础表压缩

原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-oracle-basic-table-compression/

译者 周天鹏

在关于Oracle压缩的这一系列文章中，我们会研究下传统Oracle数据库系统的各类压缩方式，这意味着该系列文章的目录结构大概是：

1. 基础表压缩

2. OLTP表压缩

3. 索引压缩

但是，不讨论Exadata的hybrid columnar compression (HCC)。

在这三种压缩技术中，索引压缩和基础表压缩是产品自带的核心组件，但是，OLTP压缩需要独立的“Advanced Compression Option (ACO)” license授权。再第一篇文章中，我们先用基础表压缩造一些数据，把对数据更新删除的问题留到第二篇文章中，最后基于前两篇的铺垫，我们再研究下OLTP的压缩。索引压缩单独留在第四、第五篇中探讨。

本文主要目的是解答一些关于表压缩相关的经常被问到的问题。

基础表压缩何时起作用？

人们经常问道，“我如何造压缩数据”，“Oracle如何解压这些数据块”，“压缩对性能会造成什么影响”，还有一个人们在使用任何新特性前都会问的问题“有啥不为人知的副作用吗？”

回答第一个问题最简单的方法就是通过一个实际例子。这里有5条SQL，跑完后我们先收集表的统计信息，然后查一下表里有多少数据块和一些其他相当信息。

-- 1. Baseline CTAS

create table t1

as

select * from all_objects where rownum <= 50000;

-- 2. CTAS with basic compression enabled

create table t1 compress basic

as

select * from all_objects where rownum <= 50000;

-- 3. Normal insert into empty table defined as compressed

create table t1 compress basic

as

select * from all_objects where rownum = 0;

insert into t1 select * from all_objects where rownum <= 50000

-- 4. Direct path insert into empty table defined as compressed

create table t1 compress basic

as

select * from all_objects where rownum = 0;

insert /*+ append */ into t1 select * from all_objects where rownum <= 50000

-- 5. CTAS without compression, then change to compressed

create table t1

as

select * from all_objects where rownum <= 50000;

alter table t1 compress basic;

alter table t1 move

每一条SQL执行完我都会运行下面的SQL查询数据块的信息：

select blocks, pct_free , compression, compress_for

from user_tables

where table_name = 'T1';

当然也有其他方法，我们可以将表空间定义为压缩的，这样在里面创建的所有表就会被默认进行压缩；我们还可以将分区表的分区或者子分区进行压缩；我们甚至可以将分区表定义为默认压缩，这样新增的分区就都是压缩的了。

我用下面这个图表总结了上述sql代码的结果：

test5有两个结果，一个是alter table move之前的，一个是之后的

当我在CTAS(create table as select)加了压缩选项时, Oracle自动将pctfree置为0 —— 这将数据块的数量显著减少，只用了189个数据块。pctfree为0意味着Oracle认为这张表将会变成read only的。但是，pctfree当然也可以设置为一个非空的值，这在后面的章节会讲。

在第三第四个测试中，我创建了一个启用了压缩的空表，然后插入数据。正如你所看到的，只有使用direct path insert，插入的数据才会被压缩。普通的insert操作并不会压缩数据。（insert后的数据块644个，相比CTAS 714个要少一些的原因是因为pctfree从10变为了0）

最后一个测试告诉我们，将表从非压缩改为压缩之后，对现存的数据并没有影响。如果你想将未压缩的数据进行压缩，需要先改变表的定义，然后move表。但是，move后需要立即重建表上的所有索引。

压缩原理并非如我们所想

Oracle如何进行压缩的呢？实际上，Oracle并不会进行压缩。他做的仅仅是块级别的深度复制。想象一下，你在一个数据块里有下面三行数据：

(‘XXXX’, ‘abcdef’, 254.32, ‘CLOSED’)

(‘XXXX’, ‘pqrstu’, 17.12, ‘CLOSED’)

(‘AAAA’, ‘abcdef’, 99.99, ‘CLOSED’)

Oracle会发现‘XXXX’出现了两次，‘abcdef’出现了两次，‘CLOSED’出现了三次。这样，就可以用这个块里重复的值创建一个字典表。压缩后的数据如下

T1 (‘XXXX’)

T2 (‘abcdef’)

T3 (‘CLOSED’)

(T1, T2, 254.32, T3)

(T1, ‘pqrstu’, 17.12, T3)

(‘AAAA’, T2, 99.99, T3)

其实，Oracle比这还要聪明，它可以重新排列块中的字段顺序，使得多个字段可以用一个标志代替。在我们的例子中，三行数据都有T1和T3。Oracle可以重排列这些字段，让这些标志尽可能的在一块，以至于可以用创建一个标志来代替两个标志的组合。最终数据会变成这样：

T1 (‘XXXX’, T2) -- 这是一个由数值和标志组合成的标志

T2 (‘CLOSED’)

T3 (‘abcdef’)

(T1, T3, 254.32) -- 注意这行只有了三列

(T1, ‘pqrstu’, 17.12) -- 同上

(‘AAAA’, T2, T3, 99.99)

让我们通过dump数据块里的数据来更进一步观察压缩的内部实现原理。这里是一个压缩表中的数据块中的第一个片段：

perm_9ir2[4]={ 2 0 1 3 }

这个表有4个数据块，但是对于这个块，Oracle重新排列了字段的顺序，意思是：字段0放在了第二位，字段1在第三位，字段2在第一位，字段3在第四位。

0x24:pti[0] nrow=65 offs=0

0x28:pti[1] nrow=400 offs=65

如上，这是数据块里的两个“表”，第一个是存放标志的“表”（其实就是字典表），有65个标志，在块的行目录中从0开始。第二个是真正的“表”，有400行，在块的行目录中从65开始。这意味着这个块的行目录一共有465个条目。

如果我们从第二个“表”（真正的数据表，而不是字典表）开始看，我们会发现这和普通的堆表中的数据块dump出来的一行没什么两样。但这里有一些特殊的点需要注意。

tab 1, row 0, @0x1b28

tl: 5 fb: --H-FL-- lb: 0x0 cc: 4

col 0: [ 4] 41 41 41 41

col 1: [10] 41 41 41 41 41 41 41 41 41 41

col 2: [ 2] c1 02

col 3: [10] 20 20 20 20 20 20 20 20 20 31

bindmp: 2c 00 01 04 31

基于列的长度（方括号中的数据），行的长度是26个字节（4+10+2+10），加上四个列4个字节 和 flag byte(fb:),lock byte(lb:),column count(cc:)每个1字节 - 但总的实际长度（tl:）只有5字节。而且最后一行也展示了这5个字节实际的数据。这5个字节分别是flag byte (0x2c = ‘–H-FL’), lock byte和存储的列数量。然后剩下2字节告诉我们有一个列是一个标志代表4个连续的值，而且我们需要到字典表中找0x31号标志。接下来让我们看下字典表中的49行（0x31）：

tab 0, row 49, @0x1ed0

tl: 19 fb: --H-FL-- lb: 0x0 cc: 4

col 0: [ 4] 41 41 41 41

col 1: [10] 41 41 41 41 41 41 41 41 41 41

col 2: [ 2] c1 02

col 3: [10] 20 20 20 20 20 20 20 20 20 31

bindmp: 00 08 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31

这个标志看起来几乎和行一样 - 但是标志的总长是19字节。所以我们看下dump出来的数据。前两个字节告诉我们这个标志在这个块里用了8次。下一个字节告诉我们标志中有4个列，通过一些编码，剩下的两个字节告诉我们这个标志的前两个字段的值实际存储在在0x36(54)和0x40(64)号标志中。后两个字段直接就是实际的数据了。

所以，通过我们的方法，从行目录到行、标志，我们可以扩展一个5字节的条目到一个完整的26字节的行。

通过我们对数据块dump出的数据进行跟踪，这里还有许多知识值得学习。

1. Oracle不会解压这些数据，他只是根据你的需求，用字典表和数据表中的数据将行重构出来。

2. 重构行的时候很可能会消耗一些额外的CPU，在做全表扫描时将尤为明显。

3. 有一个副作用，为了能重构行，Oracle必须持有某些块一段时间。所以你可能发现你的sql很少发生“consistent gets – examination”的等待，因为大部分时间花在了“cache buffers chains”的latch上面。

总 结

依然有很多关于压缩的副作用值得一提，尤其是删除和更新表的时候，这也讲引导着我们去实现OLTP的压缩 - 将来的文章会讲。

我们从这第一篇文章中发现看到了：

1. 基础压缩只有在direct path inserts时有效，普通的DML不会压缩数据。

2. Oracle会默认把压缩表的PCTFREE置为0，这也很好的表明，Oracle认为建表后你不会再修改数据。

3. 基础表压缩仅仅是把重复的值进行深度复制，但Oracle足够聪明来最小化数据占用的空间。

4. 这种深度复制机制意味着Oracle不需要解压数据，只需要把块cache在buffer cache中然后在PGA里重构行即可，该操作属于CPU密集型。