转载

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).

  所以一个初步结论如下:

  1. 一般的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在这个过程中的分析,限于篇幅和脑细胞数量,就暂时告一段落吧。

Oracle表中含有255列以上是需要注意的(r12笔记第77天)





正文到此结束
Loading...