Table Compression und Block Dump

Gestern hatte ich die Vermutung geäußert, dass ein Block Dump möglicherweise weitere Hinweise auf die technische Umsetzung der Table Compression liefern könnte. Dazu habe ich mir mit Hilfe der ORA_ROWSCN-Funktion jeweils einen Block aus einer komprimierten und einer nicht komprimierten Tabelle des gleichen Inhalts herausgesucht und dann gedumpt (die Tabellen waren compress_str_1_nocomp und compress_str_1 aus dem gestrigen Test):

-- compress_str_1: komprimiert  
alter system dump datafile 4 block 184331;
-- compress_str_1_nocomp: nicht komprimiert  
alter system dump datafile 4 block 187019;

Im Block Dump sieht man sehr viele Details, die mir zum größten Teil unklar sind, aber auch ein paar Punkte, die zu einer Deutung einladen. Zunächst erscheint ein Block, der - abgesehen von den Ids der Objekte und internen Strukturen - in beiden Varianten nahezu identisch ist:

Start dump data blocks tsn: 4 file#:4 minblk 184331 maxblk 184331
Block dump from cache:
Dump of buffer cache at level 4 for tsn=4, rdba=16961547
BH (0x000007FF47FDDCB8) file#: 4 rdba: 0x0102d00b (4/184331) class: 1 ba: 0x000007FF47C9E000
  set: 11 pool 3 bsz: 8192 bsi: 0 sflg: 2 pwc: 53,28
  dbwrid: 0 obj: 72311 objn: 72311 tsn: 4 afn: 4 hint: f
  hash: [0x000007FF5E497448,0x000007FF5E497448] lru: [0x000007FF4CFB4E20,0x000007FF47FD9B20]
  ckptq: [NULL] fileq: [NULL] objq: [0x000007FF5AC0A538,0x000007FF47FD9B48]
  st: XCURRENT md: NULL tch: 3
  flags: only_sequential_access
  LRBA: [0x0.0.0] LSCN: [0x0.0] HSCN: [0xffff.ffffffff] HSUB: [65535]
  cr pin refcnt: 0 sh pin refcnt: 0
Block dump from disk:
buffer tsn: 4 rdba: 0x0102d00b (4/184331)
scn: 0x0000.001b0d85 seq: 0x01 flg: 0x04 tail: 0x0d850601
frmt: 0x02 chkval: 0xf5cc type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x000000000E152400 to 0x000000000E154400
00E152400 0000A206 0102D00B 001B0D85 04010000  [................]
00E152410 0000F5CC 11E48C01 00011A77 001B0D80  [........w.......]
00E152420 00000000 00320003 0102D008 0000FFFF  [......2.........]
00E152430 00000000 00000000 00000000 00008000  [................]
...

In der komprimierten Version folgt dann ganz am Ende des Abschnitts (Zeile 509-511) ein Block, der den einzigen Spaltenwert der Tabelle genau einmal enthält:

00E1543D0 2C000101 00010100 61E9CF02 61616161  [...,.......aaaaa]
00E1543E0 61616161 61616161 61616161 61616161  [aaaaaaaaaaaaaaaa]
00E1543F0 61616161 30303161 30303030 0D850601  [aaaaa1000000....]

In der nicht komprimierten Version erscheint dieser Wert ab Zeile 74 (und bis Zeile 501) immer wieder:

00E152940 61210100 61616161 61616161 61616161  [..!aaaaaaaaaaaaa]
00E152950 61616161 61616161 61616161 30303161  [aaaaaaaaaaaaa100]
00E152960 30303030 2101002C 61616161 61616161  [0000,..!aaaaaaaa]
00E152970 61616161 61616161 61616161 61616161  [aaaaaaaaaaaaaaaa]
00E152980 30316161 30303030 01002C30 61616121  [aa1000000,..!aaa]
00E152990 61616161 61616161 61616161 61616161  [aaaaaaaaaaaaaaaa]
00E1529A0 61616161 31616161 30303030 002C3030  [aaaaaaa1000000,.]
...

Dann folgt in beiden Fällen wieder eine nahezu identische Passage, die auch die ITL-Sektion des Blocks darstellt:

 Object id on Block? Y
 seg/obj: 0x11a78  csc: 0x00.1b0e50  itc: 3  flg: E  typ: 1 - DATA
     brn: 0  bdba: 0x102da88 ver: 0x01 opc: 0
     inc: 0  exflg: 0
 
 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0xffff.000.00000000  0x00000000.0000.00  C---    0  scn 0x0000.001b0e50
0x02   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
0x03   0x0000.000.00000000  0x00000000.0000.00  ----    0  fsc 0x0000.00000000
bdba: 0x0102da8b
data_block_dump,data header at 0xe15247c 

Anschließend folgt auf eine Trennlinie ein Abschnitt mit Statistik-Informationen, von denen ich aber nur wenige entschlüsseln kann:

tsiz: 0x1f80
hsiz: 0x184
pbl: 0x0e15247c
     76543210
flag=--------
ntab=1
nrow=185
frre=-1
fsbo=0x184
fseo=0x4c3
avsp=0x33f
tosp=0x33f

Die nrow-Angabe zeigt die Anzahl der Sätze im Block (185 für den unkormprimierten Fall, 720 für den komprimierten) und einige andere Werte hat Jonathan Lewis gelegentlich erläutert (avsp - available space, fsbo - beginning of free space, fseo - end of free space). Einen direkten Bezug zur Komprimierung hat offenbar der nächste Abschnitt, der nur im Fall der Compression erscheint:

    r0_9ir2=0x0
    mec_kdbh9ir2=0x0
                  76543210
    shcf_kdbh9ir2=----------
              76543210
    flag_9ir2=--R----C    Archive compression: N
        fcls_9ir2[2]={ 0 32768 }

Was das genau bedeuten mag, kann ich nicht sagen.

In beiden Fällen folgt dann eine Liste der Rows mit Offset-Angaben:

0xe:pti[0]    nrow=185    offs=0
0x12:pri[0]    offs=0x1f5b
0x14:pri[1]    offs=0x1f36
0x16:pri[2]    offs=0x1f11
0x18:pri[3]    offs=0x1eec
0x1a:pri[4]    offs=0x1ec7
0x1c:pri[5]    offs=0x1ea2
0x1e:pri[6]    offs=0x1e7d
...

Anschließend folgt in beiden Fällen ein Abschnitt, der offenbar weitere Details zu den einzelnen Sätzen liefert:

-- komprimiert 
block_row_dump:
tab 0, row 0, @0x1f5c
tl: 36 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30
bindmp: 02 cf e9 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 31 30 30 30 30 30 30
tab 1, row 0, @0x1f57
tl: 5 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30
bindmp: 2c 00 01 01 00
tab 1, row 1, @0x1f52
tl: 5 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30
bindmp: 2c 00 01 01 00

-- unkomprimiert
block_row_dump:
tab 0, row 0, @0x1f5b
tl: 37 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30
tab 0, row 1, @0x1f36
tl: 37 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30
tab 0, row 2, @0x1f11
tl: 37 fb: --H-FL-- lb: 0x0  cc: 1
col  0: [33]
 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61 61
 61 31 30 30 30 30 30 30

Auffällig ist, dass die komprimierte Version zwischen einer tab 0 mit genau einer row und einer tab 1 mit 719 rows unterscheidet, während die nicht komprimierte Tabelle nur eine tab 0 mit 185 ros enthält. Vermutlich ist tab 0 die Symboltabelle mit den wiederholten Elementen. Der bindmap Eintrag, der für alle Elemente in tab 1 identisch ist, verweist dann vermutlich auf diese tab 0.

Man kann also aus dem Dump durchaus allerlei herauslesen, aber ich sehe noch nicht, welche Token in der Symboltabelle erscheinen können (obwohl viel dafür spricht, dass es sich um komplette Spaltenwerte handelt). Dazu vielleicht demnächst ein weiterer Versuch.