我也来谈谈对block空间分配的理解，呵呵

超级野人

最初由 超级野人 发布
[B]我奇怪的就是：为什么发生update时，就算是更改后row的长度比原来的短，也不会利用原来该row的空间（该空间应该是可以容纳下新row的），而是另寻位置，为什么？而且给我的感觉是：只要发现row中的某个line的长度与原来的不符合，该row就会发生迁移。（即使是row的长度没有发生变化） [/B]

大家来思考思考这个问题怎么样？

Yong Huang

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

我的试验：
create table qqq (aaa varchar(10),bbb varchar(10));
insert into qqq values('aaa','bbb');
insert into qqq values('aaa','ccc');
insert into qqq values('aaa','ddd');
insert into qqq values('aaa','eee');
dump结果：
flag=-----------
ntab=1
nrow=4
frre=-1
fsbo=0x1a
fseo=0x1f8c
avsp=0x1f72
tosp=0x1f72
0xeti[0]        nrow=4        offs=0
0x12ri[0]        offs=0x1fad
0x14ri[1]        offs=0x1fa2
0x16ri[2]        offs=0x1f97
0x18ri[3]        offs=0x1f8c
block_row_dump:
。。。。。。。。。。。。。。。。

update qqq set bbb='ppp' where bbb='ccc';
dump结果：
...
位置不是没变么！！！！！！！！！！！！！！ [/B]

I must be remembering wrong. Try delete and insert instead of update, like this:

create table t (s varchar2(3));
insert into t values ('aaa');
commit;
Dump the block
delete from t;
commit;
insert into t values ('bbb');
commit;
Dump the block

Then repeat the same test except create table t (s char(3)). I'm not sure if the commits are necessary but they're harmless.

I just did a test on 10.1.0.2.0. It looks like with varchar2, after the second insert, the block actually has 2 rows in row directory; the first row is marked D for deleted (--HDFL--) and only the second has the data, and this second row is 7 bytes closer to the block header. When the data type is char(3), there's just one row all the time.

I think I did a similar or the same test on 8.1.5 originally. Many years ago I had a bad habit of not recording my test and so it's lost in my memory!

Yong Huang

biti_rainy

最初由 超级野人 发布
[B]我奇怪的就是：为什么发生update时，就算是更改后row的长度比原来的短，也不会利用原来该row的空间（该空间应该是可以容纳下新row的），而是另寻位置，为什么？而且给我的感觉是：只要发现row中的某个line的长度与原来的不符合，该row就会发生迁移。（即使是row的长度没有发生变化） [/B]

记得前不久就这个问题探讨过

当然大约2年前年的时候我也在思考这个问题，没有一个很好的解释，那我们可以把我们所认为的优点和缺点摆出来：



当行的长度小的时候，插入原来的位置，会留下一个小空间浪费

若是插入靠近header一侧，则原来的位置被空了出来，留下一个比较大的空间

首先我们会问：这两种处理方式是否存在性能的差异，我不认为这会存在性能的差异，因为对于处理记录而言，是以行为单位一起处理的，不会是把某一个列单独提出来处理。  所以不应该存在在内存中 读数据写数据的量的差异，cpu使用时间也应该没什么明显差异。

然后，我们要关注的就是对未来 更新和插入的影响，我也不认为有什么明显的性能差异，可能需要注意的是是否对 block 空间重组周期造成差异。

我个人无法从理论上来评估两者的明显优劣，也许oracle的人作过大量的模拟测试发现这样效果更好？可能，最好，也就是问这部分的设计人员了   

当然，也许你经过各种删除、插入、更新的组合测试，可能窥出一些端倪来，如果你有兴趣可以首先尝试去做（也许什么结论都得不到）。





最后，最后提出我自己的一个遐想： 是否可能存在 这样一个状况，一个行的多个字段数据，oracle不过是格式化好写在一段buffer中，当初写代码的人没有去识别其buffer到底谁大谁小，而是简单地，compare 变化前的buffer和变化后的buffer ，若发现有差异就直接靠近header处理，若无差异就写回原来的地方。


有些东西，你也许永远不会知道为什么，甚至可能没有为什么，就是因为他如此做了，而已。 由这个问题，我们可以大胆假设，进行一些设计方面的探讨，不一定非要 猜测出一个正确的答案来。长达半月甚至一个月地思考这个问题，恐怕还不如更多地研究其他方面。因为这个问题即使解决了，其他问题还是存在的。

超级野人

另外我还有一个疑问：假设有两个tranction，分别为A,B，先后对某数据块进行操作。步骤为：
1。tranction A delete 若干行row，并提交。
2。然后，tranction b insert 若干行row。
根据我的推测，ranction b 进行insert 前，应该会遍历该数据快的row dictionary,并把空的row dictionary 项标记出来（而且应该是组成链表，以供以后插入的row dictionary 项使用），但我奇怪的是，tranction b 进行插入时，插入的第一个row并没有使用原来的空的row dictionary，而是新增加一项，从第二个row开始才会使用原来空的 row dictionary。为什么第一row没有使用原来的row dictionary呢？