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之前的,一个是之后的

Oracle压缩黑科技(一)—基础表压缩_第1张图片

当我在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密集型。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/28218939/viewspace-2147453/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/28218939/viewspace-2147453/

你可能感兴趣的:(Oracle压缩黑科技(一)—基础表压缩)