老熊的三分地-Oracle及数据恢复

接上文《Oracle压缩表数据块格式解析 PartI》，本文将分析压缩表块中实际的行数据部分。

首先我们还是先来看看行数据部分(tab 1)序号为0的行的数据：

tab 1, row 0, @0x1855
tl: 52 fb: --H-FL-- lb: 0x0  cc: 13
col  0: [ 3]  53 59 53
col  1: *NULL*
col  2: [ 5]  56 41 4c 49 44
col  3: [ 1]  4e
col  4: [ 1]  4e
col  5: [ 1]  4e
col  6: [ 2]  c1 62
col  7: [ 5]  54 41 42 4c 45
col  8: [ 7]  78 6d 03 0f 12 2a 38
col  9: [ 7]  78 6d 03 0f 12 2a 38
col 10: [19]  32 30 30 39 2d 30 33 2d 31 35 3a 31 37 3a 34 31 3a 35 35
col 11: [ 7]  41 43 43 45 53 53 24
col 12: [ 2]  c1 62
bindmp: 2c 00 0d 06 76 c9 78 79 79 79 ca c1 62 cd 54 41 42 4c 45 77 77 db 32 30 30 39 2d 30 33 2d 31 35 3a 31 37 3a 34 31 3a 35 35 cf 41 43 43 45 53 53 24 ca c1 62

bindmp那一行，与符号表中的一样，都是表示这一行数据在数据块中的原始数据，也就是压缩后的数据。我们需要把这个数据解压还原。

bindmp: 2c 00 0d 06 76 c9 78 79 79 79 ca c1 62 cd 54 41 42 4c 45 77 77 db 32 30 30 39
        2d 30 33 2d 31 35 3a 31 37 3a 34 31 3a 35 35 cf 41 43 43 45 53 53 24 ca c1 62

为了便于排版，这里把数据处理后显示为2行。

2c 行标志字节，与普通表数据块一样
00 锁标志，即ITL插槽位置
0d 这个字节表示数据被压缩后的列数，可以理解为后面的数据被分割成了几部分。
06 表示这一行中前面6列数据一定是被压缩的，具体含义在后面可以进一步解析。这一个字节，是网上很多讲压缩表格式时都没有正确地给出其意义的。
接下来的部分，与符号表类型，都是
    标志字节+数据
76 表示数据来自符号表中的序号为118(0x76)的行。
c9 依照解析符号表时的推论，应该表示接紧着后面的数据是实际的列数据，长度为1。但实际上在这里更为复杂。这里也是网上所有关于压缩表块格式分析的文章没有提到的。上面提到过”06 表示这一行中前面6列数据一定是被压缩的“，由于到这列为止，只压缩了1列，因此还没有到6列，那么这1列也是被压缩的，只不过压缩的数据没有在符号表中，而在这个字节紧接着的后面。

我们来看看上面提到的"C9”究竟代表什么？这里就不得不引入了压缩块头部中的fcls_9ir2：

fcls_9ir2[7]={ 0 32768 32768 32768 32768 32768 32768 }

这是一个数组，如果我们把数组中的每个值与0x7FFFF按位AND操作，也就是去掉最高位，就是：

fcls_9ir2[7]={ 0 0 0 0 0 0 0}

下面再来解析这个“C9”代表的意义：
0xC9=201，201-200=1，这里结果为1表示C9这个字节后面被压缩了1列数据。当然如果是CB就表示压缩了3列数据。

这里的压缩，实际上只是省略了列的长度。那么列的长度从何得知？答案就在"fcls_9ir2"。依据下面的公式：
    设当前列序号为n，n从0开始计：
    列长度=fcls_9ir2[n+1]-fcls_9ir2[n]
比如C9表示的列数1列，列序号为1，那么列长度=fcls_9ir2[2]-fcls_9ir2[1]=0，也就是这列值为NULL

再举另一个例子，这个例子的数据来源于datafile 8 block 140:

fcls_9ir2[12]={ 0 32768 32768 32768 32768 32768 32768 32768 32768 7 14 33 }

去掉fcls_9ir2中数据的最高位，结果为

fcls_9ir2[12]={ 0 0 0 0 0 0 0 0 0 7 14 33 }

我们来看这个块中的bindmp：

bindmp: 2c 00 05 0b 04 c9 78 6d 03 0f 12 2b 2f 73 d8 44 42 41 5f 41
        53 53 4f 43 49 41 54 49 4f 4e 53 cb c2 15 5e

"2c 00 05 0b 04 c9"，这里的c9同样是表示后面的是压缩数据，列数为1。只不过当前列序号n=9，因此代入公式：
    列长度=fcls_9ir2[10]-fcls_9ir2[9]=14-7=7，因此这个列的长度即为7。也就是这一列值为"78 6d 03 0f 12 2b 2f"

让我们回头继续解析本文最早的那个压缩数据bindmp：

78 79 79 79 指向符号表中的120(0x78)行、121(0x79)、121、121行，这4行共4列数据。
ca c1 62 前面解析出的压缩数据列数，已经有6列，因此这里的ca不再有特殊的含义，而是与符号表中的一样，表示本列有2字节数据，是c1 62。
cd 54 41 42 4c 45 cd表示5字节数据，为54 41 42 4c 45
77 77 指向符号表中的119行，这2行共2列数据。
db 32 30 30 39 2d 30 33 2d 31 35 3a 31 37 3a 34 31 3a 35 35 表示长度为19字节的1列数据。
cf 41 43 43 45 53 53 24 表示长度为7字节的1列数据。
ca c1 62 表示长度为2字节的1列数据。

至此，压缩后的数据，已经解了13（0x0d）项，与bindmp中的第3个字节"0d"相等，表示此行解压缩已经完成。注意这一行的列数也是13列，只不过是遇巧而已，压缩比率很高的行，在压缩后只有5部分（项）。

为了能够具有更高的压缩比率，Oracle在压缩块时，对列在块中的存储顺序可能做了调整，使得块中的数据其列序号与数据字典不再对应。数据块头部的perm_9ir2数组记录了数据列在块中实际排列的顺序。

perm_9ir2[13]={ 0 11 1 12 6 7 8 9 10 2 3 4 5 }

假设数据字典中的列序号为n，那么对于列n，在压缩的块解压后的行数据中，实际存储该列值的列序号m为：

m=perm_9ir2[n]

对于这个表，表的各个列为：

名称               是否为空? 类型
------------------ -------- -------------
OWNER                       VARCHAR2(30)
OBJECT_NAME                 VARCHAR2(128)
SUBOBJECT_NAME              VARCHAR2(30)
OBJECT_ID                   NUMBER
DATA_OBJECT_ID              NUMBER
OBJECT_TYPE                 VARCHAR2(18)
CREATED                     DATE
LAST_DDL_TIME               DATE
TIMESTAMP                   VARCHAR2(19)
STATUS                      VARCHAR2(7)
TEMPORARY                   VARCHAR2(1)
GENERATED                   VARCHAR2(1)
SECONDARY                   VARCHAR2(1)

那么，可以得到：OWNER列在块中实际的列序号为perm_9ir2[0]=0，OBJECT_NAME列在块中实际的列序号为perm_9ir2[1]=11，以此类推。

本文对Oracle压缩表数据块格式的解析，经过数据验证的范围有限，因此有可能存在错误，也欢迎发现错误的朋友及时提出。

本文解析所用的块dump出来的文件，点击此处下载。