共计 5057 个字符，预计需要花费 13 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Oracle 如何修改压缩数据，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
我们将看到只有在直接路径加载、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 , nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp; nbsp;1)
第一列是一个序列，第二列从 AAAA 到 EEEE 循环，第三列从 AAAAAAAAAA 到 JJJJJJJJJJ 循环，最后一列是 10 个字符，从 1 -50 循环(占位符用 \ nbsp; 表示)。然后我生成 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 的值，以将行迁移率控制在可接受的范围。
关于“Oracle 如何修改压缩数据”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
