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

biti_rainy

avsp and tosp in datablock dumps  

--------------------------------------------------------------------------------
Most of the free space in a data block is typically in a single area between the end of the transaction header and the start of the row data for the most recently inserted row. In a block dump fsbo and fseo are the offsets into the block where this area of free space begins and ends. When rows are inserted, they are placed at the end of this free space area, and fseo is moved up. If the row directory or ITL has to be dynamically expanded, then fsbo is moved down. The free space is kept in the middle in this way to allow both the (transaction and data) headers and row data area to grow without internal block free space management normally being required.

However, when rows are deleted or updated free space can also be created between rows in row data area. If necessary, Oracle can coalesce this fragmentary free space with the free space area by moving rows down to close up the gaps and correcting the offsets to those rows in the row directory at the top of the data area. There are several reasons why it is best for Oracle not to coalesce internal block free space immediately. In particular, it saves CPU time and reduces the retention of the exclusive buffer lock required for the change, thus improving concurrency. In a block dump tosp is the total of all free space in the block, and avsp is the readily available free space in the free space area that can be used without needing to coalesce the other free space fragments in the block, if any.

lunar2000

最初由 biti_rainy 发布
[B]5：当block重新返回freelist 再插入记录的时候，可能发生block数据的重组（row  number不变但是物理位置发生变化），到底什么时候重组，有待进一步考证 [/B]

我的理解：
物理位置变化，必然引起rowid的变化

biti_rainy

最初由 lunar2000 发布
[B]

我的理解：
物理位置变化，必然引起rowid的变化 [/B]

no no no

物理位置的变化不一定引起rowid 的变化

要明白rowid 是什么：
1：rowid 标志到具体的block 和 该记录在block中的行号
2：行号就是在block的记录的最顶端的一个序号，紧跟着有标志该记录的真实物理位置的位置
3：当物理位置发生变化的时候，行号没有改变
4：当 行迁移 发生的时候在原来 行号对应的物理位置处标记了 新的 block and row  number ，所以行迁移不用更改索引

在本测试中所有问题已经交代清楚了
希望仔细阅读

lunar2000

首先，我们看一下，8i以后的rowid的结构：
rowid用10各字节存储（80 bit），显示为18个字符（64 bit编码）
前32位是对象号
接下来的10位是文件号
接下来的22位是block号
最后16位是row号


你可以用：
select ROWID from tablename;
看看你这些变化前后的rowid的值

就算是8i以前的rowid，也仅仅是没有object no，对于，文件号，block号，row号，都是需要的

索引得时候之所以快，也是因为可以通过这些号，直接定位到数据所在地物理块中的行

所以，我不觉得物理位置改变了，rowid却没有变
如果没有变，也只能是说在那个rowid所指的位置存在一个指向实际行的连接，呵呵

biti_rainy

row  号能说明什么？
只能说明 该 row 在 block 中的编号，却不是说明 物理位置

在每个编号后面有具体的物理位置！

如下：

0x12: pti[0] offs=0x35c -------  0x12:本行号的存储的物理位置，    pti[0]  ,这里的0就是 row 号，  offs 才是真正的物理位置！
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

lunar2000

不管怎么说，首先这样说法我觉得实际意义不大，因为有多少数据在改变时就是改改offs，连row号都不变？？有多少数据的“物理位置”改变，却rowid不变得情况？我希望biti 和大家都多研究一些更具实际意义的问题。

还有，希望能够用实例证明你的论点。

biti_rainy

个人以为这个探究涉及到block内碎片的问题，pctused/pctfree 的问题……

再无聊一把，证明给你看：

SQL> create table t_row(a number, b varchar2(100));

Table created.

SQL>  insert into t_row select rownum,rownum from t where rownum < 11;

10 rows created.

SQL> commit;

Commit complete.

SQL> exec show_space('t_row');
Free Blocks.............................1
Total Blocks............................16
Total Bytes.............................131072
Unused Blocks...........................14
Unused Bytes............................114688
Last Used Ext FileId....................3
Last Used Ext BlockId...................8738
Last Used Block.........................2

PL/SQL procedure successfully completed.

SQL> alter system dump datafile 3 block 8739;

System altered.

SQL> select a,rowid from t_row;

         A ROWID
---------- ------------------
         1 AAAGbpAADAAACIjAAA
         2 AAAGbpAADAAACIjAAB   ----我们看这条记录的 rowid ，AAB 表示 行号 0*64^2 + 0*64^1 + 1 = 1
         3 AAAGbpAADAAACIjAAC
         4 AAAGbpAADAAACIjAAD
         5 AAAGbpAADAAACIjAAE
         6 AAAGbpAADAAACIjAAF
         7 AAAGbpAADAAACIjAAG
         8 AAAGbpAADAAACIjAAH
         9 AAAGbpAADAAACIjAAI
        10 AAAGbpAADAAACIjAAJ

10 rows selected.



data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x26
pbl: 0x09826c44
bdba: 0x00c02223
flag=-----------
ntab=1
nrow=10
frre=-1
fsbo=0x26
fseo=0x1f67
avsp=0x1f38
tosp=0x1f38
0xe: pti[0]        nrow=10        offs=0
0x12: pri[0]        offs=0x1f67
0x14: pri[1]        offs=0x1f6f    ----我们看这条记录的 物理位置, pri[1] 表示 row 号,offs=0x1f6f表示物理位置
0x16: pri[2]        offs=0x1f77
0x18: pri[3]        offs=0x1f7f
0x1a: pri[4]        offs=0x1f87
0x1c: pri[5]        offs=0x1f8f
0x1e: pri[6]        offs=0x1f97
0x20: pri[7]        offs=0x1f9f
0x22: pri[8]        offs=0x1fa7
0x24: pri[9]        offs=0x1faf
block_row_dump:
tab 0, row 0, @0x1f67
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 02
col  1: [ 1]  31
tab 0, row 1, @0x1f6f
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 03
col  1: [ 1]  32
tab 0, row 2, @0x1f77
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 04
col  1: [ 1]  33
tab 0, row 3, @0x1f7f
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 05
col  1: [ 1]  34
tab 0, row 4, @0x1f87
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 06
col  1: [ 1]  35
tab 0, row 5, @0x1f8f
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 07
col  1: [ 1]  36
tab 0, row 6, @0x1f97
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 08
col  1: [ 1]  37
tab 0, row 7, @0x1f9f
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 09
col  1: [ 1]  38
tab 0, row 8, @0x1fa7
tl: 8 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 0a
col  1: [ 1]  39
tab 0, row 9, @0x1faf
tl: 9 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 0b
col  1: [ 2]  31 30
end_of_block_dump


SQL> update t_row set b = 'WWWWWWWWWWW' where a = 2;

1 row updated.

SQL> commit;

Commit complete.

SQL> select a,rowid from t_row;

         A ROWID
---------- ------------------
         1 AAAGbpAADAAACIjAAA
         2 AAAGbpAADAAACIjAAB   ----rowid 没有发生改变
         3 AAAGbpAADAAACIjAAC
         4 AAAGbpAADAAACIjAAD
         5 AAAGbpAADAAACIjAAE
         6 AAAGbpAADAAACIjAAF
         7 AAAGbpAADAAACIjAAG
         8 AAAGbpAADAAACIjAAH
         9 AAAGbpAADAAACIjAAI
        10 AAAGbpAADAAACIjAAJ

10 rows selected.

SQL> alter system dump datafile 3 block 8739;

System altered.

SQL>


data_block_dump
===============
tsiz: 0x1fb8
hsiz: 0x26
pbl: 0x09826c44
bdba: 0x00c02223
flag=-----------
ntab=1
nrow=10
frre=-1
fsbo=0x26
fseo=0x1f55
avsp=0x1f2f
tosp=0x1f2f
0xe: pti[0]        nrow=10        offs=0
0x12: pri[0]        offs=0x1f67
0x14: pri[1]        offs=0x1f55 --offs=0x1f55,物理位置已经发生变化，update 的时候由于原来的空间不足，被提升到了block的最上面  
0x16: pri[2]        offs=0x1f77
0x18: pri[3]        offs=0x1f7f
0x1a: pri[4]        offs=0x1f87
0x1c: pri[5]        offs=0x1f8f
0x1e: pri[6]        offs=0x1f97
0x20: pri[7]        offs=0x1f9f
0x22: pri[8]        offs=0x1fa7
0x24: pri[9]        offs=0x1faf
block_row_dump:
tab 0, row 0, @0x1f67
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 02
col  1: [ 1]  31
tab 0, row 1, @0x1f55  物理位置发生变化
tl: 18 fb: --H-FL-- lb: 0x1 cc: 2
col  0: [ 2]  c1 03
col  1: [11]  57 57 57 57 57 57 57 57 57 57 57  变化后的数据
tab 0, row 2, @0x1f77
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 04
col  1: [ 1]  33
tab 0, row 3, @0x1f7f
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 05
col  1: [ 1]  34
tab 0, row 4, @0x1f87
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 06
col  1: [ 1]  35
tab 0, row 5, @0x1f8f
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 07
col  1: [ 1]  36
tab 0, row 6, @0x1f97
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 08
col  1: [ 1]  37
tab 0, row 7, @0x1f9f
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 09
col  1: [ 1]  38
tab 0, row 8, @0x1fa7
tl: 8 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 0a
col  1: [ 1]  39
tab 0, row 9, @0x1faf
tl: 9 fb: --H-FL-- lb: 0x0 cc: 2
col  0: [ 2]  c1 0b
col  1: [ 2]  31 30
end_of_block_dump

tigerfish

最初由 lunar2000 发布
[B]不管怎么说，首先这样说法我觉得实际意义不大，因为有多少数据在改变时就是改改offs，连row号都不变？？有多少数据的“物理位置”改变，却rowid不变得情况？我希望biti 和大家都多研究一些更具实际意义的问题。

还有，希望能够用实例证明你的论点。 [/B]

rowid里的row号也是逻辑的，真正的物理偏移量记录在block内，我想这样做的一个原因是当block内数据发生重整的时候可以不用修改索引，估计lunar没从头到尾看完整个帖子。

tigerfish

进行这样的讨论有没有意义？对于从事正常DBA工作当然没必要去太深入探讨这些算法，但估计biti正在想做个要和oracle竞争的数据库产品，正在研究算法问题，对于他来说就具有很大意义了

jlandzpa

从实验结果推算法，是有很大的难度的。