sql server中的内联blob

Question

其十六进制转储如下

00000000: 30001100 013caae4 62010000 00000000†0....<..b.......

00000010: 00060040 02002000 5c803801 02000000†...@....8.....

00000020: 0400004d 01000000 384c0000 681f0000†...M...8L..h...

00000030: e7010000 01000000 d03e0000 08020000†.........>......

00000040: 01000000 385e0000 09020000 01000000†....8^..........

00000050: 926b0000 0a020000 01000000††††††††††.k..........

记录中的一列如下所示

imageval = BLOB内联根插槽2列5偏移量0x20长度60

级别=0未使用= 77 UpdateSeq =1 TimeStamp = 1278738432

链接0

大小= 8040 RowId = (1:487:0)

链路1

大小= 16080 RowId = (1:520:0)

链路2

大小= 24120 RowId = (1:521:0)

链路3

大小= 27538 RowId = (1:522:0)

如何识别它是否是BLOB内联根。我们如何从十六进制中解释上面的值。谢谢

Answer 1

我们需要表模式来识别存储值...

这就是说：

3000 =>  
The two first flag bytes of the record.

1100 =>  
Length of the fixed length data (decimal value = 17), meaning the next 13 bytes are the fixed length data portion of the record.

013caae4 62010000 00000000 00 =>  
Fixed length data. No way to say what's what without schema.

0600 =>  
Total number of columns in the table.

40 =>  
The null bitmap array. Decimal 64 = 0b10000000 in binary, meaning the first column of the record is NULL.

0200 =>  
Number of variable length columns. Thus we can conclude you have 4 fixed-length columns since the total is 6.

2000 =>
Position offset of first variable length column. Decimal value 32. Data can thus be found from position 27-32 for a total of 6 bytes: 3801 02000000.

5c80 =>
Position offset of second variable length column. Decimal value 32.860, 0b1000000001011100 in binary. BLOB pointers are identified using the sign bit of the position offset value. Removing the sign bit from the equation gives a decimal value of 0b0000000001011100 = 92. The inline data can thus be found from bytes 33-92:

0400004d 01000000 384c0000 681f0000
e7010000 01000000 d03e0000 08020000
01000000 385e0000 09020000 01000000
926b0000 0a020000 01000000

BLOB Inline Roots start out with a header:

04 =>  
Special field type

00 =>  
Link

00 =>  
Index level

4d =>
Unused (field)

01000000 =>  
Update sequence

384c0000 =>  
Timestamp (unsigned)

And then finally we have the actual meat, an array of slot pointers:

Length   PageID   FileID  Slot
681f0000 e7010000 0100    0000
d03e0000 08020000 0100    0000
385e0000 09020000 0100    0000
926b0000 0a020000 0100    0000