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

超级野人

最初由 d.c.b.a 发布
[B]重组的定义?

我做了这样一个试验, table test4 (col1 number, col2 char(2000)), block_size为8k,所以一个block最多会有3条记录,然后我delete两条,再插入两条,发现他们的offset并没有变化,所以这个重组是指?
我用来测试的数据
insert 1 row1
insert 2 row 2
insert 3 row 3
delete 1
insert 4
delete 2
insert 5
每个语句后都加了commit和alter system checkpoint,然后dump起来看的,最后发现记录的offset竞一样.



也许我应当多做测试. [/B]

很显然，第四条记录无法利用原来删除的空间，所以数据块只有先重组，因为第4条记录使用了第一条纪录的row dictionary,而重组是按照row dictionary的顺序来安排地址的，所以offset没变

d.c.b.a

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

很显然，第四条记录无法利用原来删除的空间，所以数据块只有先重组，因为第4条记录使用了第一条纪录的row dictionary,而重组是按照row dictionary的顺序来安排地址的，所以offset没变 [/B]

经过我的试验, 不能重用是因为我的PCTUSED是40,删除一条记录后并没有降到pctused以下.

超级野人

最初由 Yong Huang 发布
[B]

Do you know what that "当无法再向后
寻找空间的时候" is? At first I thought it was  block header, i.e., data was inserted from bottom up until it reached the header. But it doesn't look like because your pri[81] is at 0x1c2f, far from the header (i.e. there're still many lower address offsets). I wonder what magic that 81st row has.

I suggest you use one column to simplify the test, once with varchar2 and once with char. I think they may show different behavior of "intra-block reorganization".

Yong Huang [/B]

老兄，说中文好不好，可能你对我的叙述理解错误，我说的pri[81]=0x1c2f，这并不是该记录的刚插入数据块时地址，刚插入时，oracle分配给pri[81]的地址应该是已经很接近block header,导致pri[82]无法再插入，于是block进行重组，pri[81]=0x1c2f应该是重组后的地址。（重组后，所有已经插入到block 的row（包括pri[81]，但不包括pri[82]，因为它还没插入）的地址都进行重新分配。

Yong Huang

最初由 超级野人 发布
[B]
我说的pri[81]=0x1c2f，这并不是该记录的刚插入数据块时地址，刚插入时，oracle分配给pri[81]的地址应该是已经很接近block header,导致pri[82]无法再插入，于是block进行重组，pri[81]=0x1c2f应该是重组后的地址。（重组后，所有已经插入到block 的row（包括pri[81]，但不包括pri[82]，因为它还没插入）的地址都进行重新分配。 [/B]

Can you show us the original offset of pri[81] ? It's not in your dump. Looks like there's a difference of 11 (0xB) between any two rows' offsets. I think pri[81] should be at 0x1c32 (i.e. 11*81+0x1fad). Can you check to see if that's its address? If so, it is different from 0x1c2f and probably results from block reorganization as you said. Nevertheless, 0x1c32 is still a big number, not close to the header.

As I said, try the experiment with both varchar and char. I vaguely remember I did the test a long time ago and found that char data causes no reorganization and just uses empty spaces, but varchar2 will, even in the case of a string replacing the same length string (like update emp set name='JOHN' where name='JACK').

Yong Huang

d.c.b.a

在我的试验中Insert并不会引起BLOCK的重组.
CREATE TABLE TEST4 (COL1 NUMBER,COL2 VARCHAR2(1000)) PCTUSED 85 PCTFREE 10;

1, Insert record
-- First block
insert into test.test4 values (1,rpad('row1',1000,'*'));
insert into test.test4 values (2,rpad('row2',600,'*'));
insert into test.test4 values (3,rpad('row3',1000,'*'));
insert into test.test4 values (4,rpad('row4',600,'*'));
insert into test.test4 values (5,rpad('row5',1000,'*'));
insert into test.test4 values (6,rpad('row6',600,'*'));
insert into test.test4 values (7,rpad('row7',1000,'*'));
insert into test.test4 values (8,rpad('row8',600,'*'));
insert into test.test4 values (9,rpad('row9',1000,'*'));
COMMIT;
alter system checkpoint;

2, dump result
DUL> ORADUMP FILE 4 BLOCK 11370
RDBA=0x01002c6a(4/11370),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d8c,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0003.057.00000046 0x008011c5.00cd.35 --U-    8 0x0000.00137d8e
Block Data:
hdsz=68
ntab=1
nrow=8
ffre=65535
fsbo=0x0066=102
fseo=0x06b4=1716
avsp=0x064e=1614
tosp=0x064e=1614
tab#=  0     nrow=   8     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x1966= 6502+  68=0x19aa= 6570   flag=--H-FL--
    row#=   2  offs=0x1575= 5493+  68=0x15b9= 5561   flag=--H-FL--
    row#=   3  offs=0x1314= 4884+  68=0x1358= 4952   flag=--H-FL--
    row#=   4  offs=0x0f23= 3875+  68=0x0f67= 3943   flag=--H-FL--
    row#=   5  offs=0x0cc2= 3266+  68=0x0d06= 3334   flag=--H-FL--
    row#=   6  offs=0x08d1= 2257+  68=0x0915= 2325   flag=--H-FL--
    row#=   7  offs=0x0670= 1648+  68=0x06b4= 1716   flag=--H-FL--

DUL> ORADUMP FILE 4 BLOCK 11371
RDBA=0x01002c6b(4/11371),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d8c,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0003.057.00000046 0x008011c5.00cd.36 --U-    1 0x0000.00137d8e
Block Data:
hdsz=68
ntab=1
nrow=1
ffre=65535
fsbo=0x0058=88
fseo=0x1c0b=7179
avsp=0x1bb3=7091
tosp=0x1bb3=7091
tab#=  0     nrow=   1     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--

3, delete where col1 in (0,2,4,6,8)
DUL> ORADUMP FILE 4 BLOCK 11370
RDBA=0x01002c6a(4/11370),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d90,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0004.058.00000044 0x0080167a.0067.08 --U-    5 0x097c.00137d91
Block Data:
hdsz=68
ntab=1
nrow=8
ffre=65535
fsbo=0x0066=102
fseo=0x06b4=1716
avsp=0x064e=1614
tosp=0x0fd2=4050
tab#=  0     nrow=   8     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x1966= 6502+  68=0x19aa= 6570   flag=--HDFL--
    row#=   2  offs=0x1575= 5493+  68=0x15b9= 5561   flag=--H-FL--
    row#=   3  offs=0x1314= 4884+  68=0x1358= 4952   flag=--HDFL--
    row#=   4  offs=0x0f23= 3875+  68=0x0f67= 3943   flag=--H-FL--
    row#=   5  offs=0x0cc2= 3266+  68=0x0d06= 3334   flag=--HDFL--
    row#=   6  offs=0x08d1= 2257+  68=0x0915= 2325   flag=--H-FL--
    row#=   7  offs=0x0670= 1648+  68=0x06b4= 1716   flag=--HDFL--

DUL> ORADUMP FILE 4 BLOCK 11371
RDBA=0x01002c6b(4/11371),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d8c,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0003.057.00000046 0x008011c5.00cd.36 --U-    1 0x0000.00137d8e
Block Data:
hdsz=68
ntab=1
nrow=1
ffre=65535
fsbo=0x0058=88
fseo=0x1c0b=7179
avsp=0x1bb3=7091
tosp=0x1bb3=7091
tab#=  0     nrow=   1     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--

4,insert into test.test4 values (2,rpad('row2',1000,'*'));

DUL> ORADUMP FILE 4 BLOCK 11370
RDBA=0x01002c6a(4/11370),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d90,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0004.058.00000044 0x0080167a.0067.08 --U-    5 0x097c.00137d91
Block Data:
hdsz=68
ntab=1
nrow=8
ffre=65535
fsbo=0x0066=102
fseo=0x06b4=1716
avsp=0x064e=1614
tosp=0x0fd2=4050
tab#=  0     nrow=   8     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x1966= 6502+  68=0x19aa= 6570   flag=--HDFL--
    row#=   2  offs=0x1575= 5493+  68=0x15b9= 5561   flag=--H-FL--
    row#=   3  offs=0x1314= 4884+  68=0x1358= 4952   flag=--HDFL--
    row#=   4  offs=0x0f23= 3875+  68=0x0f67= 3943   flag=--H-FL--
    row#=   5  offs=0x0cc2= 3266+  68=0x0d06= 3334   flag=--HDFL--
    row#=   6  offs=0x08d1= 2257+  68=0x0915= 2325   flag=--H-FL--
    row#=   7  offs=0x0670= 1648+  68=0x06b4= 1716   flag=--HDFL--

DUL> ORADUMP FILE 4 BLOCK 11371
RDBA=0x01002c6b(4/11371),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d93,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0005.003.0000004e 0x008000cf.0056.24 --U-    1 0x0000.00137d95
Block Data:
hdsz=68
ntab=1
nrow=2
ffre=65535
fsbo=0x005a=90
fseo=0x181a=6170
avsp=0x17c0=6080
tosp=0x17c0=6080
tab#=  0     nrow=   2     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x17d6= 6102+  68=0x181a= 6170   flag=--H-FL--

5, insert into test.test4 values (4,rpad('row4',1000,'*'));
DUL> ORADUMP FILE 4 BLOCK 11370
RDBA=0x01002c6a(4/11370),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d90,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0004.058.00000044 0x0080167a.0067.08 --U-    5 0x097c.00137d91
Block Data:
hdsz=68
ntab=1
nrow=8
ffre=65535
fsbo=0x0066=102
fseo=0x06b4=1716
avsp=0x064e=1614
tosp=0x0fd2=4050
tab#=  0     nrow=   8     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x1966= 6502+  68=0x19aa= 6570   flag=--HDFL--
    row#=   2  offs=0x1575= 5493+  68=0x15b9= 5561   flag=--H-FL--
    row#=   3  offs=0x1314= 4884+  68=0x1358= 4952   flag=--HDFL--
    row#=   4  offs=0x0f23= 3875+  68=0x0f67= 3943   flag=--H-FL--
    row#=   5  offs=0x0cc2= 3266+  68=0x0d06= 3334   flag=--HDFL--
    row#=   6  offs=0x08d1= 2257+  68=0x0915= 2325   flag=--H-FL--
    row#=   7  offs=0x0670= 1648+  68=0x06b4= 1716   flag=--HDFL--

DUL> ORADUMP FILE 4 BLOCK 11371
RDBA=0x01002c6b(4/11371),type=0x06,fmt=0x02,seq=0x01,flag=0x02
seg/obj=0x000010a5=4261,csc=0x0000.00137d97,itc=1,typ=1 - DATA
Transaction Slot:
id   xid-usn.slot.wrap   uba-rdba.row.seq   flag lock fsc/scn
---- ------------------- ------------------ ---- ---- ---------------
0x01 0x0002.030.00000061 0x00800553.006f.05 --U-    1 0x0000.00137d99
Block Data:
hdsz=68
ntab=1
nrow=3
ffre=65535
fsbo=0x005c=92
fseo=0x1429=5161
avsp=0x13cd=5069
tosp=0x13cd=5069
tab#=  0     nrow=   3     offs=   0
    row#=   0  offs=0x1bc7= 7111+  68=0x1c0b= 7179   flag=--H-FL--
    row#=   1  offs=0x17d6= 6102+  68=0x181a= 6170   flag=--H-FL--
    row#=   2  offs=0x13e5= 5093+  68=0x1429= 5161   flag=--H-FL--
[/FONT]

超级野人

最初由 Yong Huang 发布
[B]

Can you show us the original offset of pri[81] ? It's not in your dump. Looks like there's a difference of 11 (0xB) between any two rows' offsets. I think pri[81] should be at 0x1c32 (i.e. 11*81+0x1fad). Can you check to see if that's its address? If so, it is different from 0x1c2f and probably results from block reorganization as you said. Nevertheless, 0x1c32 is still a big number, not close to the header.

As I said, try the experiment with both varchar and char. I vaguely remember I did the test a long time ago and found that char data causes no reorganization and just uses empty spaces, but varchar2 will, even in the case of a string replacing the same length string (like update emp set name='JOHN' where name='JACK').

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结果：
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:

位置不是没变么！！！！！！！！！！！！！！

超级野人

最初由 d.c.b.a 发布
[B]在我的试验中Insert并不会引起BLOCK的重组.
CREATE TABLE TEST4 (COL1 NUMBER,COL2 VARCHAR2(1000)) PCTUSED 85 PCTFREE 10;

[/B]

你delete后进行commit了没有，为什么要用两个数据块呢，我觉得应该只用一个数据块进行试验，结果才正确。

d.c.b.a

当然是commit了, 你只看第一个block就可以了，不能限制这个表达到了maxextent啊.

超级野人

如果有两个block的话，插入的时候，就不确定将使用哪个数据快了，哪又怎能确定第一个数据块会不会发生重组呢。（重组是要满足一定条件的，就是oralce要使用该数据块进行插入，而数据块的尾部空间已经用完了）。

d.c.b.a

我认为在INSERT时，还是先找一个有足够空间的BLOCK，进行INSERT，而不优先选择重组.