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

grassbell

最初由 qf_123 发布
[B]为什么我不能使用exec show_space('tn');
系统提示我说我要先定义show_space，请问用这个有什么限制吗？ [/B]

参照：
http://www.itpub.net/showthread. ... 697&pagenumber=

grassbell

又重温了一遍，发现这个帖子也清楚地表现了 row chaining 和 row migration 两个概念。另外，提出了自己的问题。

biti_rainy said:
2：当删除记录后的空间，如果新插入的数据能容纳进去，则重用

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

And my question:
我注意到，虽然row都是从block的底部向header方向插入，但是用insert into tn select ......一次性插入多行，则是从header向tail方向插入的。

问题是：你首先删除了6，7两行，又插入了(19,'q') 和(19,'qqq'); 虽然这两行都比先前删除的两行短，足可以利用原来的空间。实际的情况只是(19,'qqq') 重用了第6行在row dictionary中的row entry，但新插入的两行的物理位置都在第0行的物理位置之上（靠近row header，这时的插入方向是对的）。也就是并没有重用删除的空间。

wyq21973

看得头大也要看看。

biti_rainy

最初由 grassbell 发布
[B]又重温了一遍，发现这个帖子也清楚地表现了 row chaining 和 row migration 两个概念。另外，提出了自己的问题。

biti_rainy said:
2：当删除记录后的空间，如果新插入的数据能容纳进去，则重用

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

And my question:
我注意到，虽然row都是从block的底部向header方向插入，但是用insert into tn select ......一次性插入多行，则是从header向tail方向插入的。

问题是：你首先删除了6，7两行，又插入了(19,'q') 和(19,'qqq'); 虽然这两行都比先前删除的两行短，足可以利用原来的空间。实际的情况只是(19,'qqq') 重用了第6行在row dictionary中的row entry，但新插入的两行的物理位置都在第0行的物理位置之上（靠近row header，这时的插入方向是对的）。也就是并没有重用删除的空间。 [/B]

thanks ,我测试的时候没有注意只是使用了 row  dictionary 而没有使用删除部分的空间。 多谢指出。

herycom

哈哈，我也来凑热闹了。
研究这个用处不大，不同版本的oracle结构不一样吧？
除非取得oracle的支持，否则谁能够保证能完全正确读取数据？
一但有一点错误，就会有问题，就不能实际使用。
人家从oracle出来的都不能完全保证正确，谁知道oracle以后的版本，以后的补丁会不会对存取增加点什么？
我劝大家放弃吧。

biti_rainy

最初由 herycom 发布
[B]哈哈，我也来凑热闹了。
研究这个用处不大，不同版本的oracle结构不一样吧？
除非取得oracle的支持，否则谁能够保证能完全正确读取数据？
一但有一点错误，就会有问题，就不能实际使用。
人家从oracle出来的都不能完全保证正确，谁知道oracle以后的版本，以后的补丁会不会对存取增加点什么？
我劝大家放弃吧。 [/B]

这本来就是一种兴趣，想搞清楚一个问题，研究的人没有人在乎是否有用，也都清楚对于应用实际用处不大。但是仅仅是对技术的执着而已，从设计思想上理解，而已。

能搞清楚这些问题的人，不会傻到认为这会对数据库应用软件开发带来直接的益处吧

超级野人

最初由 biti_rainy 发布
[B]3： 当更新的时候，如果  row  长度没有增加，则位置不变，如果长度增加，则被迁移到整个块的最前记录之前（靠近 block  header 一侧）
[/B]

怎么这个结论和我做的实验结果不符合呢：
来看我的试验：

1。先建一个表： create table qqq (aaa varchar(10),bbb number);
2。插入数据：
begin
for i in 1..250 loop
insert into qqq values('aaaaaa',i);
end loop;
end;
3。 dump结果：
0xeti[0]        nrow=250        offs=0
0x12ri[0]        offs=0x1fab
0x14ri[1]        offs=0x1f9e
0x16ri[2]        offs=0x1f91
0x18ri[3]        offs=0x1f84
0x1ari[4]        offs=0x1f77
0x1cri[5]        offs=0x1f6a
0x1eri[6]        offs=0x1f5d
0x20ri[7]        offs=0x1f50
0x22ri[8]        offs=0x1f43
0x24:pri[9]        offs=0x1f36
0x26:pri[10]        offs=0x1f29
0x28:pri[11]        offs=0x1f1c
0x2a:pri[12]        offs=0x1f0f
..............................
4。更改数据： update qqq set aaa='aaa' where bbb=10;
5。dump结果：
0xe:pti[0]        nrow=250        offs=0
0x12:pri[0]        offs=0x1fab
0x14:pri[1]        offs=0x1f9e
0x16:pri[2]        offs=0x1f91
0x18:pri[3]        offs=0x1f84
0x1a:pri[4]        offs=0x1f77
0x1c:pri[5]        offs=0x1f6a
0x1e:pri[6]        offs=0x1f5d
0x20:pri[7]        offs=0x1f50
0x22:pri[8]        offs=0x1f43
0x24:pri[9]        offs=0x1267
0x26:pri[10]        offs=0x1f29
0x28:pri[11]        offs=0x1f1c
0x2a:pri[12]        offs=0x1f0f
...................................

可以看到：虽然更改的数据长度变小了，但是pri[9]的offs已经发生了变化，并不保留在原位置。这样看来，似乎update的过程就是先delete，后insert.

biti_rainy

当初我的实验是有缺陷的，数据长度变小我没有测试，这也会导致位置移动，这个有人后来指出过.

由此我也想一个问题，如果更新一行记录中的某个字段变小，如果不移动后面的字段的话在行内就形成了空洞，与其如此还不如干脆放到最上面，如果字段更新后长度没变就正好填满原来的地方。

超级野人

最初由 biti_rainy 发布
[B]当初我的实验是有缺陷的，数据长度变小我没有测试，这也会导致位置移动，这个有人后来指出过.

由此我也想一个问题，如果更新一行记录中的某个字段变小，如果不移动后面的字段的话在行内就形成了空洞，与其如此还不如干脆放到最上面，如果字段更新后长度没变就正好填满原来的地方。 [/B]

为什么不移动后面的字段？如果放到最上面，那还不是要复制所有的字段到另一个位置。

biti_rainy

最初由 超级野人 发布
[B]

为什么不移动后面的字段？如果放到最上面，那还不是要复制所有的字段到另一个位置。 [/B]

也许，你移动后面的字段，依然造成一个 微小 的  洞，又或者，整体移到上面很方便，原样放回是恰好利用原来的空间。

为什么总是要抓住  复制 这样一个概念,如果你要如此讲，请去弄清楚oracle的buffer处理机制再说吧，当然，我也不清楚buffer处理数据的时候的详细情形。在buffer中可能都不过是一个拷贝的过程，拷贝100字节和1000字节，这个差异本来就很小，其消耗资源的过程对于整个dml的执行，简直就可以忽略不计吧。



再要继续，你去问oracle的设计者吧