概述

近期一个客户的一张单表，每天delete7天前的数据，每天的数据增量没什么变化，理论上来说，delete释放的空间是可重用的，但发现该表段最近一直在增长，现在大小为300G，170G的75% – 100% free space blocks.通常通过 APPEND，直接路径加载的方式会直接扩展SEGMENT，不会重用DELETE的空间，但客户的系统排除了APPEND INSERT。

测试目的

我们知道ASSM的表INSERT查找可用空间机制，会在L2 Hint for inserts指上的L2块，再通过算法确定L1块，查找存在可用空间的数据块，完成INSERT。

客户的系统里，发现一个现象，DUMP SEGMENT HEADER，发现L2 Hint for inserts一直指向最后一个L2块。Segment Type: 1 nl2: 37 blksz: 8192 fbsz: 0L2 Array start offset: 0x00001434First Level 3 BMB: 0x00000000L2 Hint for inserts: 0x1fd54208 <<<

如果ORACLE只是通过L2块查找可用空间，L2 Hint for inserts总是指向最后的L2的话，之前L2块所管理的数据块上数据被DELETE掉，那也没有重用的机会。正常的系统不应该是这样的，下面在我的机器上做一个测试，验证存在多个L2块的系统上，如果前面的L2块管理的块上数据DELETE掉，在表扩展之前，会修改 L2 Hint for inserts的指向，到前面有可用空间的L2，从而重用DELETE释放的空间。

测试步骤如下：

1、创建测试表SQL> create table TEST.tab1(id number,c varchar2(1000)) tablespace users;Table created.

2、INSERT数据，直接产生1个以上L2块为止。我这里有两个L2insert into TEST.tab1 select 0*100000+rownum,rpad('a',1000,'a') from dual connect by rownum<100000;insert into TEST.tab1 select 1*100000+rownum,rpad('a',1000,'a') from dual connect by rownum<100000;insert into TEST.tab1 select 40*100000+rownum,rpad('a',1000,'a') from dual connect by rownum<100000;这里INSERT了大400万数据SQL> @seg test.tab1SEG_MB OWNER SEGMENT_NAME SEG_PART_NAME SEGMENT_TYPE SEG_TABLESPACE_NAME BLOCKS HDRFIL HDRBLK---------- -------------------- ------------------------------ ------------------------------ -------------------- ------------------------------ ---------- ---------- ----------4608 TEST TAB1 TABLE USERS 589824 23 130SQL>SQL> alter system dump datafile 23 block 130;System altered.Segment Type: 1 nl2: 2 blksz: 8192 fbsz: 0L2 Array start offset: 0x00001434First Level 3 BMB: 0x00000000L2 Hint for inserts: 0x05c82088 <<<

3、当前的空间实用情况set serverout onexec show_space('TAB1','TEST');Total Blocks............................589824Total Bytes.............................4831838208Unused Blocks...........................0Unused Bytes............................0Last Used Ext FileId....................23Last Used Ext BlockId...................581760Last Used Block.........................8192*************************************************The segment is analyzed0% -- 25% free space blocks.............00% -- 25% free space bytes..............025% -- 50% free space blocks............125% -- 50% free space bytes.............819250% -- 75% free space blocks............050% -- 75% free space bytes.............075% -- 100% free space blocks...........23775% -- 100% free space bytes............1941504Unused Blocks...........................2816Unused Bytes............................23068672Total Blocks............................585709Total bytes.............................4798128128PL/SQL procedure successfully completed.

4、 DELETE 50万数据，因为我INSERT是顺序的，DELETE id<500000的数据，应该释放的是段的前面的一批BLOCKSSQL> delete TEST.tab1 where id<500000;499995 rows deleted.commit;

5、再查看空间使用情况

75% – 100% free space blocks从DELETE前的237 增长到 71665。set serverout onexec show_space('TAB1','TEST');SQL>SQL> Total Blocks............................589824Total Bytes.............................4831838208Unused Blocks...........................0Unused Bytes............................0Last Used Ext FileId....................23Last Used Ext BlockId...................581760Last Used Block.........................8192*************************************************The segment is analyzed0% -- 25% free space blocks.............00% -- 25% free space bytes..............025% -- 50% free space blocks............125% -- 50% free space bytes.............819250% -- 75% free space blocks............050% -- 75% free space bytes.............075% -- 100% free space blocks...........71665 <<<<75% -- 100% free space bytes............587079680Unused Blocks...........................2816Unused Bytes............................23068672Total Blocks............................514281Total bytes.............................4212989952PL/SQL procedure successfully completed.SQL>

6、INSERT 999行数据进行测试

因为当前 L2 Hint for inserts指向的L2上仍然有可用空间，会发现下面的INSERT并没有使用DELETE释放的这部分空间。SQL> insert into TEST.tab1 select 0+rownum,rpad('a',1000,'a') from dual connect by rownum<1000;999 rows created.SQL> SQL> commit;Commit complete.SQL> select EXTENT_ID,FILE_ID,BLOCK_ID,BLOCKS from dba_extents where tablespace_name='USERS' and owner='TEST' and segment_name='TAB1' order by extent_id;EXTENT_ID FILE_ID BLOCK_ID BLOCKS---------- ---------- ---------- ----------0 23 128 81 23 136 82 23 144 83 23 152 84 23 160 85 23 168 86 23 176 87 23 184 88 23 192 89 23 200 810 23 208 811 23 216 812 23 224 813 23 232 814 23 240 815 23 248 816 23 256 12817 23 384 12818 23 512 12819 23 640 12820 23 768 12821 23 896 12822 23 1024 12823 23 1152 128....----该段的前部分块上并没有我们刚刚INSERT的数据，说明没有重用DELETE的空间。SQL> select id,dbms_rowid.rowid_relative_fno(rowid) file_id,dbms_rowid.rowid_block_number(rowid) block_id from TEST.tab1 where2 rowid >=dbms_rowid.rowid_create(1,73129,23,127,1) and rowid <=dbms_rowid.rowid_create(1,73129,23,1024,500)3 and id<100;no rows selected

7、继续INSERT 10万行数据

因为最后的L2块上，高水位下面没有这么多的空间存放这10万行数据，可以看到这次重用了之前DELETE释放的空间，同时看到L2 Hint for inserts现在指向到了第一个L2块。SQL> insert into TEST.tab1 select 0+rownum,rpad('a',1000,'a') from dual connect by rownum<100000;99999 rows created.SQL> commit;Commit complete.----INSERT 10万行后，Total Blocks 589824，表总BLOCKS没有增长，75% -- 100% free space blocks从71665减少到60053SQL> set serverout onSQL> exec show_space('TAB1','TEST');Total Blocks............................589824Total Bytes.............................4831838208Unused Blocks...........................0Unused Bytes............................0Last Used Ext FileId....................23Last Used Ext BlockId...................581760Last Used Block.........................8192*************************************************The segment is analyzed0% -- 25% free space blocks.............10% -- 25% free space bytes..............819225% -- 50% free space blocks............025% -- 50% free space bytes.............050% -- 75% free space blocks............050% -- 75% free space bytes.............075% -- 100% free space blocks...........6005375% -- 100% free space bytes............491954176Unused Blocks...........................0Unused Bytes............................0Total Blocks............................528709Total bytes.............................4331184128PL/SQL procedure successfully completed.---可以看到前段的1000个块上有我们刚刚INSERT的数据，说明重用了DELETE释放的空间SQL> select id,dbms_rowid.rowid_relative_fno(rowid) file_id,dbms_rowid.rowid_block_number(rowid) block_id from TEST.tab1 where2 rowid >=dbms_rowid.rowid_create(1,73129,23,127,1) and rowid <=dbms_rowid.rowid_create(1,73129,23,10240,500)3 and id<100000 and rownum<100;ID FILE_ID BLOCK_ID---------- ---------- ----------20445 23 17720446 23 17720447 23 17720448 23 17720449 23 17720450 23 17720451 23 177。。。。。。。。20418 23 18820419 23 18820420 23 18820421 23 18820422 23 18820423 23 18820424 23 18920425 23 18920426 23 18920427 23 18920428 23 18920429 23 18920430 23 18920431 23 19020432 23 19020433 23 19020434 23 19020435 23 19020436 23 19020437 23 19020438 23 19199 rows selected.SQL>SQL> alter system dump datafile 23 block 130;System altered.L2 Hint for inserts的指向也从第二个L2块，换成了第一个L2块。Extent Control Header-----------------------------------------------------------------Extent Header:: spare1: 0 spare2: 0 #extents: 255 #blocks: 589824last map 0x00000000 #maps: 0 offset: 2716Highwater:: 0x05c90080 ext#: 254 blk#: 8192 ext size: 8192#blocks in seg. hdr's freelists: 0#blocks below: 588763mapblk 0x00000000 offset: 254Unlocked--------------------------------------------------------Low HighWater Mark :Highwater:: 0x05c90080 ext#: 254 blk#: 8192 ext size: 8192#blocks in seg. hdr's freelists: 0#blocks below: 588763mapblk 0x00000000 offset: 254Level 1 BMB for High HWM block: 0x05c8e087Level 1 BMB for Low HWM block: 0x05c8e087--------------------------------------------------------Segment Type: 1 nl2: 2 blksz: 8192 fbsz: 0L2 Array start offset: 0x00001434First Level 3 BMB: 0x00000000L2 Hint for inserts: 0x05c00081 <<<<<

总结

猜测正常情况下，L2 Hint for inserts指向的L2块找不到可用空间的时侯，在尝试ALLOCATE新的EXTENT的前，会去判断之前的L2块有没有可用空间。如果有，会修改L2 Hint for inserts，去使用之前的L2管理的块上释放出来的空间。

客户环境中，大量75% – 100% free space blocks的情况下，INSERT不重用释放的空间问题，还需要继续分析！

作者

范计杰，云和恩墨技术顾问，5年大型ORACLE数据库维护经验，擅长性能调优、故障处理等。

墨天轮原文链接：https://www.modb.pro/db/43425(复制到浏览器或者点击“阅读原文”立即查看)