原文鏈接
譯者 周天鵬
在本系列的第一篇文章中，我們看到了只有在直接路徑加載、CTAS( table as )和"alter table move"時(shí)，基礎(chǔ)表壓縮機(jī)制才可以生效。同時(shí)當(dāng)表啟用了壓縮時(shí)oracle用戶授權(quán)表空間，會默認(rèn)的將該表中數(shù)據(jù)塊的設(shè)置為0，這也暗示了我們基礎(chǔ)壓縮應(yīng)該作為一種只讀數(shù)據(jù)的壓縮策略。
當(dāng)我們查看一個(gè)對應(yīng)塊的dump文件時(shí)，會發(fā)現(xiàn)并不是“壓縮”數(shù)據(jù)，他所做的是在每個(gè)塊上創(chuàng)建重復(fù)值列表（即字典表），然后通過一些標(biāo)志來代替那些重復(fù)值從而達(dá)到塊級別的去重。并且，可以重新排列塊中的字段順序，從而增加用一個(gè)標(biāo)志來代替多個(gè)字段的機(jī)會。這告訴我們，在讀取塊時(shí)并不需要“解壓”數(shù)據(jù)，他需要做的僅僅是通過指針來重構(gòu)數(shù)據(jù)，當(dāng)然這是一個(gè)CPU密集型操作。
在這篇文章中，我們將討論如果不遵從只讀原則將會發(fā)生什么。然后，我們將會在第三篇文章中探討需要另外授權(quán)的OLTP壓縮。如前所述，以下所有示例都來自 11.2.0.3的實(shí)例。
去重與刪除
你可以回憶下上篇文章中，我把一個(gè)包含組合標(biāo)志的數(shù)據(jù)塊的一行dump出來，然后遞歸的向上查找這個(gè)標(biāo)志代表的意義，最終確定該組合標(biāo)志由兩個(gè)單獨(dú)的標(biāo)志和兩個(gè)額外的字段值組合而成，下面就是我們測試的那行：
tab 1, row 0, @
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
: 2c 00 01 04 31
這是我們在查找引用的單個(gè)標(biāo)志的值時(shí)所發(fā)現(xiàn)的**49號標(biāo)志**：
Tab 0, row 49, @
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
: 00 08 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31
中的前5個(gè)字節(jié)告訴我們這個(gè)標(biāo)志在這個(gè)塊中使用了8次(00 08),由4個(gè)列組成，然后我們來看看54(0x36)和64(0x40)號標(biāo)志：
tab 0, row 54, @
tl: 7 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [ 4] 41 41 41 41
: 00 0a cc 41 41 41 41
tab 0, row 64, @
tl: 13 fb: --H-FL-- lb: 0x0 cc: 1
col 0: [10] 41 41 41 41 41 41 41 41 41 41
: 00 05 d2 41 41 41 41 41 41 41 41 41 41
從上面的dump數(shù)據(jù)我們可以猜到oracle用戶授權(quán)表空間，如果想要?jiǎng)h除原始行，就必須進(jìn)行額外的工作。 \
有兩件事必然會發(fā)生：
1. 該行必須標(biāo)志為已刪除(以正常的方式)，
2. **49號標(biāo)志**的“使用計(jì)數(shù)”也必須減少1。
在刪除一行之后，這里有一個(gè)小的片段，首先是行條目本身：
tab 1, row 0, @
tl: 2 fb: --HDFL-- lb: 0x2
: 3c 02
以下是**49號標(biāo)志**的二進(jìn)制轉(zhuǎn)儲，注意，第二個(gè)字節(jié)：
: 00 07 04 36 40 ca c1 02 d2 20 20 20 20 20 20 20 20 20 31
所以我們可以意識到，即使是刪除簡單的一行，也會使維護(hù)塊數(shù)據(jù)的工作增加。但是這個(gè)標(biāo)志同時(shí)也在塊的其他7行中使用，所以如果我刪除這些行，會發(fā)生什么?答案取決于刪除的并發(fā)會話數(shù)量。如果我使用一個(gè)進(jìn)程來刪除所有8行，在刪除第8行時(shí)，刪除了標(biāo)志，此時(shí)63號標(biāo)志和64號標(biāo)志必須更新，以顯示它們?nèi)鄙倭艘粋€(gè)依賴項(xiàng)。如果我重復(fù)測試使用多個(gè)會話來刪除行，并且在每次刪除后不提交，那么我就可以看到一個(gè)場景，標(biāo)志顯示為零，但不會消失。(也有可能我還沒有觀察到的一些后續(xù)的塊清理操作將會清除這個(gè)狀態(tài)的標(biāo)志。)
在我提到并發(fā)測試之前，我沒有提到任何關(guān)于提交或回滾的內(nèi)容。標(biāo)志的改變發(fā)生在這個(gè)動作上，并且之后并沒有提交。如果我提交或回滾會發(fā)生什么?
在提交時(shí)，可能會發(fā)生通常的提交清除操作，用提交時(shí)的SCN更新事務(wù)的ITL插槽（換句話說，沒有新的或特別的事情發(fā)生）。在回滾時(shí)，數(shù)據(jù)根據(jù)undo信息恢復(fù)，任何已經(jīng)被刪除的標(biāo)志也將被重新創(chuàng)建，任何相關(guān)標(biāo)志的使用數(shù)都會增加。
但重點(diǎn)是，回滾之后，壓縮依然會保留。雖然這些行會在回滾后寫入塊的空閑空間，但在原始塊和回滾后的塊之間還是有一些區(qū)別。因?yàn)檫@樣的操作需要塊經(jīng)過空閑空間碎片的整合操作。所以如果你再次將塊dump出來，你可以看到塊的內(nèi)容已經(jīng)被移動了。在我的例子里（刪除了引用49號標(biāo)志的8行記錄，然后回滾），我看到了如下的區(qū)別：
tab 0, row 49, @ -- of token 0
tab 0, row 49, @ -- of token 0 after
tab 1, row 0, @ -- of row 0
tab 1, row 0, @ -- of row 0 after
壓縮與空閑空間
當(dāng)你刪除然后回滾數(shù)據(jù)后，行就會移動，這個(gè)現(xiàn)象引出了關(guān)于空閑空間非常有趣的一點(diǎn)——當(dāng)你的表是基礎(chǔ)壓縮的時(shí)候，默認(rèn)的就是0了。沒有空閑空間，但有空間給我在回滾后移動數(shù)據(jù)用？
我發(fā)現(xiàn)確實(shí)會保留一點(diǎn)點(diǎn)空間（大約幾十byte，但對于我測試用例里的兩整行也是絕對足夠了）。這一小部分空間允許恢復(fù)那些已被刪除的行。有些情況，這部分剩余空間甚至能讓你做操作。
我來微調(diào)下我的初始數(shù)據(jù)集，每一行看起來如下:
(, 'AAAA', '','1')
第一列是一個(gè)序列，第二列從AAAA到EEEE循環(huán)，第三列從到循環(huán)，最后一列是10個(gè)字符，從1-50循環(huán)(占位符用"\"表示)。然后我生成800行數(shù)據(jù)。由于我創(chuàng)建數(shù)據(jù)的方法問題，第一個(gè)數(shù)據(jù)塊中有11行數(shù)據(jù)，第二第三列都是A，所以我需要運(yùn)行如下sql然后dump表中的第一個(gè)塊來觀察發(fā)生了什么。
t1
set
= 'BBBB'
where
= 'AAAA'
and = ''
and