Oracle表中含有255列以上时需要注意的(r12笔记第77天)
Oracle表中含有255列以上时需要注意的(r12笔记第77天)
今天看JL(Jonathan Lewis)的一篇文章，真是费了不少的脑细胞，玩Oracle几十年的老司机，看问题的角度和深度果然不一样，当时看他的大作《Oracle核心技术》就花了我不少时间，还没有看完，一本薄薄的书能够蕴含如此的能量，做技术到了这个火候，让人深深佩服。
他的一篇博文，标题很简单，就是“255 again”看来是一个很经典的问题，我就简单抓取一些测试的思路和脚本来说说。
原文在链接 https://jonathanlewis.wordpress.com/2017/05/23/255-again/ 如果你的某张表列数超过255个，你就需要注意了，会有一些特别的问题出现，而对于这个问题的模拟，JL提供了一个脚本，会创建320个字段，然后对这个表插入一行数据，更新一行数据，然后根据block的dump来做一个分析和说明,脚本如下：
rem
rem Script: wide_table_4.sql
rem Author: Jonathan Lewis
rem Dated: May 2017
rem
rem Last tested
rem 12.2.0.1
rem 12.1.0.2
rem 11.2.0,4
rem
set pagesize 0
set feedback off
spool temp.sql
prompt create table t1(
select
'col' || to_char(rownum,'fm0000') || ' varchar2(10),'
from
all_objects
where rownum <= 320
;
prompt col0321 varchar2(10)
prompt )
prompt /
spool off
@temp
set pagesize 40
set feedback on
insert into t1 (col0010, col0280) values ('0010','0280');
commit;
update t1 set col0320 ='0320';
commit;
column file_no new_value m_file_no
column block_no new_value m_block_no
select
dbms_rowid.rowid_relative_fno(rowid) file_no,
dbms_rowid.rowid_block_number(rowid) block_no,
dbms_rowid.rowid_row_number(rowid) row_no
from
t1
;
alter system flush buffer_cache;脚本执行后，会创建一个含有320个字段的表，然后对标所在的dump做一个trace。
ntab=1
nrow=2
frre=-1
fsbo=0x16
fseo=0x1e54
avsp=0x1e3e
tosp=0x1f13
0xe:pti[0] nrow=2 offs=0
0x12:pri[0] offs=0x1e7a
0x14:pri[1] offs=0x1e54
block_row_dump:
tab 0, row 0, @0x1e7a
tl: 49 fb: -------- lb: 0x2 cc: 40
nrid: 0x014000a7.0
col 0: *NULL*
col 1: *NULL*
col 2: *NULL*
...
col 37: *NULL*
col 38: *NULL*
col 39: *NULL*
tab 0, row 1, @0x1e54
tl: 38 fb: --H-F--- lb: 0x2 cc: 25
nrid: 0x014000a3.0
col 0: *NULL*
col 1: *NULL*
col 2: *NULL*
...
col 22: *NULL*
col 23: *NULL*
col 24: *NULL*
end_of_block_dump有几个点需要注意，这个块被分成了两部分，"row 1"所在的那部分这个块的起点（可以通过fb中的标记H,意思就是header），可以从末尾的cc看出涉及的列有25个，行的下一部分可以通过nrid来看，就是nrid: 0x014000a3.0转换过来就是5号数据文件，163号数据块，这个和row 1所在的数据库相同。
如果我们看row 0的时候，会根据基本信息得到，它涉及的列数有40个，40个列都是空的，这一行指向的下行地址是nrid: 0x014000a7.0这个地址转换过来是在5号数据文件的167号块，根据这一行中间的标注(为空），感觉是一个可有可无的部分。我们就继续对5号数据文件的167号块做一个dump,得到的信息如下：
fsbo=0x14
fseo=0x1e76
avsp=0x1e62
tosp=0x1e62
0xe:pti[0] nrow=1 offs=0
0x12:pri[0] offs=0x1e76
block_row_dump:
tab 0, row 0, @0x1e76
tl: 266 fb: -----L-- lb: 0x1 cc: 255
col 0: *NULL*
col 1: *NULL*
col 2: *NULL*
...
col 251: *NULL*
col 252: *NULL*
col 253: *NULL*
col 254: [ 4] 30 33 32 30
end_of_block_dump 通过上面的信息可以发现，这是行数据的最后一部分，可以通过哪个L得到，（即last）.
所以一个初步结论如下:
- 一般的insert语句会把使用到的280个列分成两部分（25,255），这个280列可以通过Insert语句看到。
insert into t1 (col0010, col0280) values ('0010','0280'); 2.在updae的场景中，我们把使用到的列从280升到了320
update t1 set col0320 ='0320';所以说在update的场景中，我们可以把列的使用情况从280改进到了320个列，这40个列在orale中会跟255为分界来处理，这样就是（40,295），然后把40列放在原来的数据块中，剩下的把255个列迁移到一个新的块中，所以这样一来，原来列的的分布就很有特点了，分配到了两个块中。后面还有对于ASSM在这个过程中的分析，限于篇幅和脑细胞数量，就暂时告一段落吧。