关于block中数据的存储和重组的探究

biti_rainy

SQL> insert into tn values(1,1,1);

1 row created.

SQL> commit;

Commit complete.

SQL>  alter system dump datafile 3 block 1955;

System altered.

再插入记录，我们看看位置，我们发现该块并没有被插入记录，记录是插入到了 另外一个块（虽然该块现在空间使用率并不高）
这是因为在update的时候先脱离了freelist然后又回到freelist了，排在了 block 1956 之后
Block header dump:  0x00c007a3
Object id on Block? Y
seg/obj: 0x66b7  csc: 0x00.1891ba5  itc: 1  flg: O  typ: 1 - DATA
     fsl: 1  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   xid:  0x0004.047.000000e7    uba: 0x00800618.00df.08  --U-   11  fsc 0x1b2e.01891ba7

data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x28
pbl: 0x0ba76c44
bdba: 0x00c007a3
flag=-----------
ntab=1
nrow=11
frre=7
fsbo=0x28
fseo=0x2f6
avsp=0x3d0
tosp=0x1efe
0xe: pti[0]        nrow=11        offs=0
0x12: pti[0]        offs=0x35c
0x14: pti[1]        offs=0x34b
0x16: pti[2]        offs=0x33a
0x18: pti[3]        offs=0x329
0x1a: pti[4]        offs=0x318
0x1c: pti[5]        offs=0x307
0x1e: pti[6]        offs=0x2f6
0x20: pti[7]        sfll=-1
0x22: pti[8]        offs=0x7f0
0x24: pti[9]        offs=0x7da
0x26: pti[10]        offs=0x760
block_row_dump:
tab 0, row 0, @0x35c
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 1, @0x34b
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 03
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 2, @0x33a
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 04
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 3, @0x329
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 05
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 4, @0x318
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 06
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 5, @0x307
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 07
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 6, @0x2f6
tl: 17 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 14
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 8, @0x7f0
tl: 9 fb: --H----- lb: 0x1 cc: 0
nrid:  0x00c007a4.0
tab 0, row 9, @0x7da
tl: 9 fb: --H----- lb: 0x1 cc: 0
nrid:  0x00c007a4.1
tab 0, row 10, @0x760
tl: 9 fb: --H----- lb: 0x1 cc: 0
nrid:  0x00c007a4.2
end_of_block_dump
End dump data blocks tsn: 2 file#: 3 minblk 1955 maxblk 1955

biti_rainy

SQL> insert into tn select 1,1,1 from all_objects where rownum < 1001;

1000 rows created.

SQL> commit;

Commit complete.

SQL>  alter system dump datafile 3 block 1955;

System altered.

SQL>

再插入1000条记录，我们发现其中600条插到了 block 1956中，而本块只插入了400条，这是因为freelist中的顺序问题
并且我们发现，本块中原来存在的记录已经完全重新组织过，物理位置都因为insert而发生了变化
也就是说oracle 的 block中的记录物理位置是可能重组的，但不变的是 行号，这个行号和物理位置记录在  前部，供通过
rowid 查询的时候快速定位

Block header dump:  0x00c007a3
Object id on Block? Y
seg/obj: 0x66b7  csc: 0x00.1891bab  itc: 1  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   xid:  0x0006.01e.000000f2    uba: 0x00801660.00da.14  --U-  400  fsc 0x0000.01891bad

data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x346
pbl: 0x0ba76c44
bdba: 0x00c007a3
flag=-----------
ntab=1
nrow=410
frre=-1
fsbo=0x346
fseo=0xf86
avsp=0xc40
tosp=0xc40
0xe: pti[0]        nrow=410        offs=0
0x12: pti[0]        offs=0x1fa7   先前的7条记录物理位置已经发生变化但是行号没有改变
0x14: pti[1]        offs=0x1f96   先前的7条记录物理位置已经发生变化但是行号没有改变
0x16: pti[2]        offs=0x1f85   先前的7条记录物理位置已经发生变化但是行号没有改变
0x18: pti[3]        offs=0x1f74   先前的7条记录物理位置已经发生变化但是行号没有改变
0x1a: pti[4]        offs=0x1f63   先前的7条记录物理位置已经发生变化但是行号没有改变
0x1c: pti[5]        offs=0x1f52   先前的7条记录物理位置已经发生变化但是行号没有改变
0x1e: pti[6]        offs=0x1f41   先前的7条记录物理位置已经发生变化但是行号没有改变
0x20: pti[7]        offs=0x18b4   该行号已经被新的记录插入
0x22: pti[8]        offs=0x1f38   该行迁移发生的记录没有发生变化，这是因为这样不用更新索引
0x24: pti[9]        offs=0x1f2f   该行迁移发生的记录没有发生变化，这是因为这样不用更新索引
0x26: pti[10]        offs=0x1f26   该行迁移发生的记录没有发生变化，这是因为这样不用更新索引
0x28: pti[11]        offs=0x18be   新插入的记录
0x2a: pti[12]        offs=0x18c8   新插入的记录
0x2c: pti[13]        offs=0x18d2   新插入的记录
0x2e: pti[14]        offs=0x18dc   新插入的记录
0x30: pti[15]        offs=0x18e6   新插入的记录
0x32: pti[16]        offs=0x18f0   新插入的记录
0x34: pti[17]        offs=0x18fa   新插入的记录
0x36: pti[18]        offs=0x1904   新插入的记录
……………………………………………………
省略掉一些
block_row_dump:
tab 0, row 0, @0x1fa7
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 02
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 1, @0x1f96
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 03
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 2, @0x1f85
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 04
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 3, @0x1f74
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 05
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 4, @0x1f63
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 06
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 5, @0x1f52
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 07
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 6, @0x1f41
tl: 17 fb: --H-FL-- lb: 0x0 cc: 3
col  0: [ 2]  c1 14
col  1: [ 7]  71 71 71 71 71 71 71
col  2: [ 2]  70 70
tab 0, row 7, @0x18b4
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 8, @0x1f38
tl: 9 fb: --H----- lb: 0x0 cc: 0
nrid:  0x00c007a4.0
tab 0, row 9, @0x1f2f
tl: 9 fb: --H----- lb: 0x0 cc: 0
nrid:  0x00c007a4.1
tab 0, row 10, @0x1f26
tl: 9 fb: --H----- lb: 0x0 cc: 0
nrid:  0x00c007a4.2
tab 0, row 11, @0x18be
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 12, @0x18c8
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 13, @0x18d2
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 14, @0x18dc
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 15, @0x18e6
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31
col  2: [ 1]  31
tab 0, row 16, @0x18f0
tl: 10 fb: --H-FL-- lb: 0x1 cc: 3
col  0: [ 2]  c1 02
col  1: [ 1]  31

省略掉后面重复的数据

biti_rainy

1： 当block中开始插入数据的时候，正常插入
2：当删除记录后的空间，如果新插入的数据能容纳进去，则重用
3： 当更新的时候，如果  row  长度没有增加，则位置不变，如果长度增加，则被迁移到整个块的最前记录之前（靠近 block  header 一侧）
4：当发生行迁移的时候，在原物理位置保留  迁移后的 block位置和 row  number
5：当block重新返回freelist 再插入记录的时候，可能发生block数据的重组（row  number不变但是物理位置发生变化），到底什么时候重组，有待进一步考证

biti_rainy

biti_rainy wrote:
结论

1： 当block中开始插入数据的时候，正常插入
2：当删除记录后的空间，如果新插入的数据能容纳进去，则重用
3： 当更新的时候，如果 row 长度没有增加，则位置不变，如果长度增加，则被迁移到整个块的最前记录之前（靠近 block header 一侧）
4：当发生行迁移的时候，在原物理位置保留 迁移后的 block位置和 row number
5：当block重新返回freelist 再插入记录的时候，可能发生block数据的重组（row number不变但是物理位置发生变化），到底什么时候重组，有待进一步考证

观点2，有一个transaction freelist的概念，就是说，当没有commit之前，这个session delete导致的空余Block，即使没有返回freelist,也能被这个session重用。如果是新插入的数据，别的session 重用的条件是返回process freelist,就是过了pctused之后，这个就是你说的第五点。
你说的第四点，就是我们一般说的row migration.

你说的第五点颇有一点新颖的见解，是别的地方都没有看到过的说法。不知道和你说的第三点有什么异同？

biti_rainy

chao_ping wrote:

你说的第五点颇有一点新颖的见解，是别的地方都没有看到过的说法。不知道和你说的第三点有什么异同？


我这里的观点2 不是针对 freelist 的,一个block本身位于freelist中，但在block中因为delete而释放出来的空间能被insert 重用，也就是说block的空间的利用对于insert不是 循环使用的，是从tail 到 header凡是能容纳的空间都可以使用，但在update而言，却都始终是提升到靠近 header一侧的

这里我没有提到 transaction freelist
因为这样的话这个话题就要 详细的论述 freelist甚至 freelist group 了，所以我忽略了提出这个论点

当然 row change 大家也都知道，只不过这里更直观的让大家看见： 瞧，row change 的本质特征就是这个样子的，oracle就是这么存放的

第5点中的，和第3点区别大了，这也是一个以前疑惑的地方，在第三点中，重组或者变化的数据，仅仅是update的记录，这个时候把update的那条记录提升到block靠近header一侧

但我发现，在block中空间比较零散或者被使用的少部分空间位于block的header一侧而tail一侧是空闲的话，在insert的时候会导致空间重构，也就是说原来在靠近header一侧位置存储的数据，在insert发生之前被 迁移 到block的tail位置，发生了空间的重组。 这样在本质上就是block内空间的重组，也就是说 在block级别的空间重组是自动的，而segment 级别的就必须采用exp/imp, alter ...... move ,ctas 等等方式

biti_rainy

idler wrote:
上面说明了INSERT和DELETE之间的一些关系,BITI再详细解释一下上面的一些问题吧?
下面再来做个UPDATE的实验.


当delete 一条数据的时候，真切地删除了数据，但是并没有修改前面的地址标志

我们来思考这个问题： 为什么？
假如我们根据rowid 来查询数据，就是在前面地址记录处找到 row number 然后定位到物理位置

假如你修改了前面的标志，那么当要rollback的时候就找不着原来的位置了，也就是rollback后真实的物理位置可能要发生变化

还有一个问题是：

因为commit的时候只修改回滚段事务表而不用修改block(否则代价太高)，而如果在delete 的时候就把 前面位置信息给 去掉了，那当其他事务的记录insert 的时候就可能使用到这部分空间，也使用了这个 row number ，当然，实际上你虽然可以说，去insert的时候判定该行的TX是否还活动…… ，办法总是有的，但代价似乎太高了

站在通过一系列的解决这些复杂的关系之后我们再来想另外一个问题：
假如相同的事务删除了记录，然后insert 又重复使用了这个位置，然后又update 了这个记录导致行位置发生了变化，甚至由于update 而发生了行迁移到其他block，那你说，这时我再要 rollback， 我们不清楚rollback的时候是不是按照roll forword 的时候的顺序 颠倒 过来做的，恐怕颠倒过来做很麻烦，可如果是按照先前的 DML 的顺序依次做 rollback 则一定回退不了了； 就算颠倒过来做，这个过程可就异常复杂了！！！！

我这里仅仅是从理论上来探讨 假如delete 的时候就把前面物理标志也修改掉的可能性，我的结论是很困难。
所以我想oracle采取了简单的方式，就跟恢复的时候 前滚 和回退 似的，全部前滚了再一起回退，这样处理起来简单多了

biti_rainy

注意，其中有字段跨越了 block

由这个例子可以看出，一个行在写入的时候实际上数据是倒着写的
假设存在着字段 1,2,3,4,5
先写字段5--4---3--2---1
当跨越block的时候，是字段1和2的前24字节在相临的第二个block
也就是说连字段数据都是靠近末尾部分先写进block
而行若存在索引，则rowid 指向的block实际上应该是在 第二个block，第二个block保存着剩下部分数据的指针


SQL> create table blocks(a char(2000),b char(2000), c char(2000),d char(2000),e char(2000));

Table created.

SQL> set serverout on
SQL> exec show_space('blocks');
Free Blocks.............................0
Total Blocks............................16
Total Bytes.............................131072
Unused Blocks...........................15
Unused Bytes............................122880
Last Used Ext FileId....................3
Last Used Ext BlockId...................32226
Last Used Block.........................1

PL/SQL procedure successfully completed.

SQL> insert into blocks values (1,1,1,1,1);

1 row created.

SQL> commit;

Commit complete.

SQL> alter system dump datafile 3 block min 32227 block max 32228;

System altered.

*** 2003-04-15 14:54:39.078
Start dump data blocks tsn: 2 file#: 3 minblk 32227 maxblk 32228
buffer tsn: 2 rdba: 0x00c07de3 (3/32227)
scn: 0x0000.01892035 seq: 0x01 flg: 0x02 tail: 0x20350601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

Block header dump:  0x00c07de3
Object id on Block? Y
seg/obj: 0x66c3  csc: 0x00.1892033  itc: 1  flg: -  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   xid:  0x0003.01d.000000e9    uba: 0x00800dac.00d9.28  --U-    1  fsc 0x0000.01892035

data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x14
pbl: 0x02556c44
bdba: 0x00c07de3
flag=-----------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x81
avsp=0x6d
tosp=0x6d
0xeti[0]        nrow=1        offs=0    本块只有一条记录
0x12ri[0]        offs=0x81  本记录从 本块的 129个字节为开始  0x81  =  8*16 + 1 =  129
block_row_dump:
tab 0, row 0, @0x81
tl: 7991  本block中 行长度为 7991， 7991  + 129 =  8192 = block_size 8k  fb: -----LP- lb: 0x1 cc: 4 (本block包含4个字段内容)
col  0: [1976]  ------这里只存放了本字段的后1976个字节
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
*************************************************************************   -------  表示省略相同部分数据的显示
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20
col  1: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
***********************************************************************
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col  2: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
**********************************************************************
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col  3: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
*************************************************************************
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
end_of_block_dump




buffer tsn: 2 rdba: 0x00c07de4 (3/32228)
scn: 0x0000.01892035 seq: 0x01 flg: 0x02 tail: 0x20350601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data

Block header dump:  0x00c07de4
Object id on Block? Y
seg/obj: 0x66c3  csc: 0x00.1892033  itc: 1  flg: O  typ: 1 - DATA
     fsl: 0  fnx: 0x0 ver: 0x01

Itl           Xid                  Uba         Flag  Lck        Scn/Fsc
0x01   xid:  0x0003.01d.000000e9    uba: 0x00800dac.00d9.29  --U-    1  fsc 0x0000.01892035

data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x14
pbl: 0x02556c44
bdba: 0x00c07de4
flag=-----------
ntab=1
nrow=1
frre=-1
fsbo=0x14
fseo=0x17c3
avsp=0x17af
tosp=0x17af
0xeti[0]        nrow=1        offs=0
0x12ri[0]        offs=0x17c3
block_row_dump:
tab 0, row 0, @0x17c3
tl: 2037 fb: --H-F--N lb: 0x1 cc: 2  -----本block只保存着本行的2个字段 ,关于 fb  的内容偶暂时不能解读，应该跟 行迁移 和行连接有关
nrid:  0x00c07de3.0   ------- 表示存在着部分数据在 block 0x00c07de3 的 row 0  的行上
col  0: [2000]
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
**************************************************************************
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
col  1: [24] ---第二个字段在本块只保存了24个字节
31 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
end_of_block_dump
End dump data blocks tsn: 2 file#: 3 minblk 32227 maxblk 32228

biti_rainy

关于fb:
fb  Flag Byte:
            K = Cluster Key  (Flags may change meaning
     if this is set to show HASH cluster)
                 C = Cluster table member
                 H = Head piece of row
                 D = Deleted row
                 F = First data piece
                 L = Last data piece
                 P = First column continues from previous piece
                 N = Last column continues in next piece

tigerfish

biti , pctused的问题，我觉得可以判断
avsp=0x6d
tosp=0x6d
这两项

biti_rainy

最初由 tigerfish 发布
[B]biti , pctused的问题，我觉得可以判断
avsp=0x6d
tosp=0x6d
这两项 [/B]

avsp : 表示block中的 HWM, 也就是曾经到达过的最高的地方

tosp: 表示所有数据压缩后存储的话所到达的地方，也就是表示block内数据的大小，也表示 pctused 的值

但目前还没有确定由哪几个参数可决定什么时候 block 内空间重构