Oracle压缩黑科技（二）—压缩数据的修改

原文链接 https://www.red-gate.com/simple-talk/sql/oracle/compression-in-oracle-part-2-read-only-data/

译者  周天鹏 

在本系列的第一篇文章中，我们看到了只有在直接路径加载、CTAS(create table as select)和"alter table move"时，基础表压缩机制才可以生效。同时当表启用了压缩时，Oracle会默认的将该表中数据块的pctfree设置为0，这也暗示了我们基础压缩应该作为一种只读数据的压缩策略。

当我们查看一个对应块的dump文件时，会发现Oracle并不是“压缩”数据，他所做的是在每个块上创建重复值列表（即字典表），然后通过一些标志来代替那些重复值从而达到块级别的去重。并且，Oracle可以重新排列块中的字段顺序，从而增加用一个标志来代替多个字段的机会。这告诉我们，Oracle在读取块时并不需要“解压”数据，他需要做的仅仅是通过指针来重构数据，当然这是一个CPU密集型操作。

在这篇文章中，我们将讨论如果不遵从只读原则将会发生什么。然后，我们将会在第三篇文章中探讨需要另外授权的OLTP压缩。如前所述，以下所有示例都来自Oracle 11.2.0.3的实例。

去重与删除

你可以回忆下上篇文章中，我把一个包含组合标志的数据块的一行dump出来，然后Oracle递归的向上查找这个标志代表的意义，最终确定该组合标志由两个单独的标志和两个额外的字段值组合而成，下面就是我们测试的那行：

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

这是我们在查找引用的单个标志的值时所发现的**49号标志**：

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

bindmp中的前5个字节告诉我们这个标志在这个块中使用了8次(00 08),由4个列组成，然后我们来看看54(0x36)和64(0x40)号标志：