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在這種情況下做了什麼樣的最佳化。