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

在本系列的第一篇文章中，我们看到了只有在直接路径加载、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)号标志：

tab 0, row 54, @0x1f74
tl: 7 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 41 41 41 41
bindmp: 00 0a cc 41 41 41 41


tab 0, row 64, @0x1f7b
tl: 13 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [10] 41 41 41 41 41 41 41 41 41 41
bindmp: 00 05 d2 41 41 41 41 41 41 41 41 41 41

从上面的dump数据我们可以猜到，如果想要删除原始行，就必须进行额外的工作。

有两件事必然会发生：

1. 该行必须标志为已删除(以正常的方式)，

2. **49号标志**的“使用计数”也必须减少1。

在删除一行之后，这里有一个小的片段，首先是行条目本身：

tab 1, row 0, @0x1b28
tl: 2 fb: --HDFL-- lb: 0x2
bindmp: 3c 02

以下是**49号标志**的二进制转储，注意，第二个字节：

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

所以我们可以意识到，即使是删除简单的一行，也会使维护块数据的工作增加。但是这个标志同时也在块的其他7行中使用，所以如果我删除这些行，会发生什么?答案取决于删除的并发会话数量。如果我使用一个进程来删除所有8行，在删除第8行时，Oracle删除了标志，此时63号标志和64号标志必须更新，以显示它们缺少了一个依赖项。如果我重复测试使用多个会话来删除行，并且在每次删除后不提交，那么我就可以看到一个场景，标志显示为零，但不会消失。(也有可能我还没有观察到的一些后续的块清理操作将会清除这个状态的标志。)

在我提到并发测试之前，我没有提到任何关于提交或回滚的内容。标志的改变发生在delete这个动作上，并且之后并没有提交。如果我提交或回滚会发生什么?

在提交时，可能会发生通常的提交清除操作，用提交时的SCN更新事务的ITL插槽（换句话说，没有新的或特别的事情发生）。在回滚时，数据根据undo信息恢复，任何已经被删除的标志也将被重新创建，任何相关标志的使用数都会增加。

但重点是，回滚之后，压缩依然会保留。虽然这些行会在回滚后写入块的空闲空间，但在原始块和回滚后的块之间还是有一些区别。因为这样的操作需要块经过空闲空间碎片的整合操作。所以如果你再次将块dump出来，你可以看到块的内容已经被移动了。在我的例子里（删除了引用49号标志的8行记录，然后回滚），我看到了如下的区别：

tab 0, row 49, @0x1ed0 -- original position of token 0
tab 0, row 49, @0x134a -- position of token 0 after rollback


tab 1, row 0, @0x1b28 -- original position of row 0
tab 1, row 0, @0x1322 -- position of row 0 after rollback

压缩与空闲空间

当你删除然后回滚数据后，行就会移动，这个现象引出了关于空闲空间非常有趣的一点——当你的表是基础压缩的时候，默认的pctfree就是0了。没有空闲空间，但有空间给我在回滚后移动数据用？

我发现Oracle确实会保留一点点空间（大约几十byte，但对于我测试用例里的两整行也是绝对足够了）。这一小部分空间允许Oracle恢复那些已被删除的行。有些情况，这部分剩余空间甚至能让你做update操作。

我来微调下我的初始数据集，每一行看起来如下:

 (1000001, 'AAAA', 'AAAAAAAAAA','         1')

第一列是一个序列，第二列从AAAA到EEEE循环，第三列从AAAAAAAAAA到JJJJJJJJJJ循环，最后一列是10个字符，从1-50循环(占位符用" "表示)。然后我生成800行数据。由于我创建数据的方法问题，第一个数据块中有11行数据，第二第三列都是A，所以我需要运行如下sql然后dump表中的第一个块来观察发生了什么。

update t1
set
        vc_rep = 'BBBB'
where
        vc_rep = 'AAAA'
and     vc_cycle = 'AAAAAAAAAA'
and     rownum <= 4
;

这证明了这个块里有足够的空间来更新这两行记录，而且始终在同一个块里，但是我的行还是发生了迁移。这里有这个数据块中某行在操作前后的dump数据对比：

tab 1, row 0, @0x1bb8 -- before
tl: 11 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: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 00 02 03 1b cd c4 02 01 01 02


tab 1, row 0, @0x4f3 -- after
tl: 37 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 42 42 42 42
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 02 04 00 cc 42 42 42 42 d2 41 41 41 41 41 41 41 41 41 41 d2 20 20 20 20 20 20 20 20 20 31 cd c4 02 01 01 02

在update操作后，Oracle将该行扩展成了完整的四列数据。有两个标志在字典表中，可以被用来替换更新的这行记录的前两个字段。但是Oracle并没有去试图寻找并使用这些标志。所以，这么看来，好像update压缩的数据就会造成整体的混乱，一行压缩的记录可能会扩展的及其巨大，微不足道的那点空闲空间无法装下这些数据，最终引发了行的迁移。

虽然我们现在看来，当出现扩展的行以及迁移的行之后，数据会有点混乱。但当我们执行回滚操作时，Oracle会把这些混乱清理干净，而且剩余的行也都会在原始压缩的、未迁移的位置。

所以update操作到底能造成多么糟糕的影响？回答这个问题之前，我们可以先看下我所做的update操作。我修改了一个标志可以代替的值，而且该值在很多行中都存在。但如果我修改了一个标志无法代替的值呢？Oracle还会因为这个update来扩展这行记录吗？答案是否定的。如果我们修改了ID(序列类型，不重复，无法标志化)的值。下面是修改前会的dump数据对比：

tab 1, row 0, @0x1bb8 -- before
tl: 11 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: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 5] c4 02 01 01 02
bindmp: 2c 00 02 03 1b cd c4 02 01 01 02


tab 1, row 0, @0x1bb8 -- after
tl: 10 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 41 41 41 41
col 1: [10] 41 41 41 41 41 41 41 41 41 41
col 2: [10] 20 20 20 20 20 20 20 20 20 31
col 3: [ 4] c3 64 64 64
bindmp: 2c 02 02 03 1b cc c3 64 64 64

update操作后的数据依然在原来的位置，并未发生迁移。但是请注意该行由一个可代表前三行的标志和一个实际的值组成。行扩展并未发生。

我初始测试的那行数据实际上整行都可以被一个标志所代替。如果我更新一个被多个标志组合起来的行中的某个标志化的字段会怎样？Oracle并不会扩展整行——它只会扩展update操作影响的那列的数据。这里是操作前后的dump数据：

tab 1, row 18, @0x1ac2
tl: 13 fb: --H-FL-- lb: 0x0 cc: 4
col 0: [ 4] 44 44 44 44
col 1: [10] 58 58 58 58 58 58 58 58 58 58
col 2: [10] 20 20 20 20 20 20 20 20 33 34
col 3: [ 5] c4 02 01 01 14
bindmp: 2c 00 04 03 32 37 45 cd c4 02 01 01 14


tab 1, row 18, @0x1ab8
tl: 23 fb: --H-FL-- lb: 0x2 cc: 4
col 0: [ 4] 44 44 44 44
col 1: [10] 59 59 59 59 59 59 59 59 59 59
col 2: [10] 20 20 20 20 20 20 20 20 33 34
col 3: [ 5] c4 02 01 01 14
bindmp: 2c 02 04 00 32 d2 59 59 59 59 59 59 59 59 59 59 45 cd c4 02 01 01 14

在这个测试的最开始，dump数据就表明了这行由三个独立的标志(0x32, 0x37和0x45)和一个实际数值组成。我将第一列的值‘XXXXXXXXXX’更新为‘YYYYYYYYYY’，正如你所见，最后一块dump数据依然包含标志0x32和0x45，但是标志0x37已经被实际值所替换掉。你也可以看到行的长度增加了10字节（从13b增加到23b），这意味着Oracle不得不把它移动到那很小的一部分空闲空间中，所以最终行的地址发生了变化。

所以当你试图更新基础表压缩中的数据时，Oracle可能将标志扩展为实际值，但它会尽可能的做最小化的扩展。即使数据在压缩后pctfree为0的情况下数据块中依然有一小部分空间。所以虽然你可以在不造成大量扩展以及行迁移的情况下做一些极小量的update操作，但这些副作用几乎不可能被预知。

如果你确实需要对已压缩的数据做一些小量的维护操作，就需要对实际数据做足够多的测试来寻找最合适的pctfree的值，以将行迁移率控制在可接受的范围。

总 结

• 当你从压缩表中删除数据时，会消耗一些额外的CPU，因为Oracle要维护字典表来减少相关标志的引用数量，然后当引用数为零后将该标志删除；除此之外，除了当标志使用量为0但该标志没被删除时的那一点点的空间浪费，过多的删除操作并不会造成很大的危害。
• 当你更新压缩表中的数据时，你不得不时刻提醒自己，Oracle已经将pctfree置为0了，所以只有少的可怜的一点点空间给你的行用来增长使用，除非你人为的把pctfree调高一点。
• 如果你更新了一个被标志化的字段值，Oracle会生成一个该行的副本，然后修改副本中的标志为完整的值——修改后即使字典表中有该值对应的标志，Oracle也不会将该值进行压缩。但缺点是你会发现update压缩数据会导致大量行数据的扩展以及严重的行迁移。
• 一个基础的指导方针——除非你非常的了解你的数据，否则只有只读数据才适合启用基础压缩。下一篇文章我们会看下OLTP压缩，来看看Oracle在这种情况下做了什么样的优化。