SecureFile LOB - more inserts

This blog post continues with all the objects and settings from SecureFile LOB - the empty table, SecureFile LOB - the 1st insert and SecureFile LOB - the 1st update. 

The next insert is a small LOB with 2 bytes again:

insert into berx.TEST_BLOBS
select 2, comments, file_content
from berx.source_blobs
where id=2; 
--2 byte 

The table row points to a new block in the LOB segment:

ROWID   = AABu7gAAEAAA+N/AAA
ROWNUM  = 1
LOBID   = 00000001000099BF67D1
EXTENT# = 0
HOLE?   = n
Superchunk cont? = n
Overallocation  = n
rdba   = 17032590 - 0x  103E58E
File   = 4
Block  = 255374
nblks  = 1
offset = 0
length = 2
---

It's the 4th trans data block:

Block dump from disk:
buffer tsn: 4 rdba: 0x0103e58e (4/255374)
scn: 0xa9c.b1d49a00 seq: 0x02 flg: 0x04 tail: 0x9a000602
frmt: 0x02 chkval: 0x4617 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FDC9B903800 to 0x00007FDC9B905800
7FDC9B903800 0000A206 0103E58E B1D49A00 04020A9C  [................]
...
Block header dump:  0x0103e58e
 Object id on Block? Y
 seg/obj: 0x6ef63  csc: 0xa9c.b1d49a00  itc: 1  flg: E  typ: 5 - LOCAL LOBS
     fsl: 0  fnx: 0xffffffff ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x01b0.011.000210a9  0x00000000.0000.00  -B--    0  fsc 0x0000.00000000
========
bdba    [0x0103e58e]
kdlich  [0x7fdc9b90384c 56]
  flg0  0x20 [ver=0 typ=data lock=n]
  flg1  0x00
  scn   0x0a9c.b1d49a00
  lid   00000001000099bf67d1
  rid   0x00000000.0000
kdlidh  [0x7fdc9b903864 24]
  flg2  0x00 [ver=0 lid=short-rowid hash=n cmap=n pfill=n]
  flg3  0x00
  pskip 0
  sskip 0
  hash  0000000000000000000000000000000000000000
  hwm   2
  spr   0
  data  [0x7fdc9b903880 52 8060]
41 42 00 6f 00 74 00 68 00 65 00 72 00 5f 00 78 00 6d 00 6c 00 3e 00 3c 00 69

The structure is well known already, lid is equal to LOBID, hwm is 2 bytes and the content is 0x41 0x42 which is A B.

There is no change in any of the Hash Bucket blocks (neither UFS nor CFS).

---

the 2nd insert is

insert into berx.TEST_BLOBS
select 3, comments, file_content
from berx.source_blobs
where id=3; 
--4 kbyte 

Again only 1 block.

ROWID   = AABu7gAAEAAA+N/AAB
ROWNUM  = 1
LOBID   = 00000001000099C090E3
EXTENT# = 0
HOLE?   = n
Superchunk cont? = n
Overallocation  = n
rdba   = 17032587 - 0x  103E58B
File   = 4
Block  = 255371
nblks  = 1
offset = 0
length = 4038
---

the LOB is now stored in 0x0103e58b - the 1st trans data block. It was used at the 1st insert, but not in use anymore since the 1st update - since then it was on the UFS list.

buffer tsn: 4 rdba: 0x0103e58b (4/255371)
scn: 0xa9c.b1d52068 seq: 0x02 flg: 0x04 tail: 0x20680602
frmt: 0x02 chkval: 0x7711 type: 0x06=trans data
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FF37EF64800 to 0x00007FF37EF66800
7FF37EF64800 0000A206 0103E58B B1D52068 04020A9C  [........h ......]
7FF37EF64810 00007711 00000005 0006EF63 B1D52068  [.w......c...h ..]
7FF37EF64820 00000A9C 00220001 FFFFFFFF 001D01A9  [......".........]
7FF37EF64830 00001782 00000000 00000000 00004000  [.............@..]
7FF37EF64840 00000000 00000000 00000000 B1D52068  [............h ..]
7FF37EF64850 00200A9C 01000000 C0990000 0000E390  [.. .............]
7FF37EF64860 00000000 00000000 00000000 00000000  [................]
7FF37EF64870 00000000 00000000 00000000 00000FC6  [................]
7FF37EF64880 6C636564 0D657261 2020200A 20202020  [declare..       ]
7FF37EF64890 44495220 20202020 574F5220 0D3B4449  [ RID     ROWID;.]
...
Block header dump:  0x0103e58b
 Object id on Block? Y
 seg/obj: 0x6ef63  csc: 0xa9c.b1d52068  itc: 1  flg: E  typ: 5 - LOCAL LOBS
     fsl: 0  fnx: 0xffffffff ver: 0x01

 Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   0x01a9.01d.00001782  0x00000000.0000.00  -B--    0  fsc 0x0000.00000000
========
bdba    [0x0103e58b]
kdlich  [0x7ff37ef6484c 56]
  flg0  0x20 [ver=0 typ=data lock=n]
  flg1  0x00
  scn   0x0a9c.b1d52068
  lid   00000001000099c090e3
  rid   0x00000000.0000
kdlidh  [0x7ff37ef64864 24]
  flg2  0x00 [ver=0 lid=short-rowid hash=n cmap=n pfill=n]
  flg3  0x00
  pskip 0
  sskip 0
  hash  0000000000000000000000000000000000000000
  hwm   4038
  spr   0
  data  [0x7ff37ef64880 52 8060]

Also, nothing fancy here. Everything as expected.

There is another block of interest, the UFS Hash Bucket which UFS List points to this block. It did NOT change and still contains block 0x0103e58b:

Block dump from disk:
buffer tsn: 4 rdba: 0x0103e583 (4/255363)
scn: 0xa9c.916207e5 seq: 0x01 flg: 0x04 tail: 0x07e53d01
frmt: 0x02 chkval: 0xa4e3 type: 0x3d=NGLOB: Hash Bucket
Hex dump of block: st=0, typ_found=1
Dump of memory from 0x00007FF37EF64800 to 0x00007FF37EF66800
...
  Dump of Hash Bucket Block
  --------------------------------------------------------
Hash Bucket Header Dump
Inst:1 Flag:6 Total:0 FSG_COUNT:0 OBJD:454499 Inc:0
Self Descriptive
 fsg_count:0
Head:0x 0x00000000  Tail:0x 0x00000000
 Opcdode:3 Locker Xid: 0x01b0.019.00020f35
Fsbdba: 0x0    Fbrdba: 0x0
Head Cache Entries
-------------------
-------------------
Tail Cache Entries
-------------------
-------------------
Free Space Chunk Summary
Inst:0 Minc:0 Maxc:0 Count:0 Tot:0 MAXC:1
UFS List
--------------
Deleted - Chunk:0 DBA: 0x0103e58b Len:140681653780481 Xid: 0x01b0.019.00020f35 Ctime:1504343585
Scn: 0x0a9c.9062fe3c
  --------------------------------------------------------

this looks confusing: How can a block which is in use be present in a Free Space list?
My assumption here: as the blocks SCN (0x0a9c.b1d52068) is higher than the UFS entry SCN (0x0a9c.9062fe3c), I'd claim the UFS entry outdated and a cleanup will happen when there is a need to write this Hash Bucket block.