一、 Extents分配管理机制
你需要管理informix数据库以避免“extent overflow”,当一个表抵达它的最大被允许的extent上限数值时,将会发生数据处理停止的现象。
表extents数量值较高可能威胁到这个系统的可用性,因为未来它们将引发停机风险且需要立即重整表。下图显示在informix数据库怎样分配和管理extents。
尽管可能存在某些对性能的影响,但通常extents溢出不会引发性能的下降,因为你的系统使用索引优化访问。但是,数量值较高的extents可能引起批量访问方面的问题。
1. 以下机制弱化extents问题的产生
·Extent融合
一般,一个新extent将被分配到一个邻近存在的extent后,且遵循以下原则,尽可能不导致数量增长过多且分配的存储区域尽量连续。
· Extent分配值翻倍
当一个表占用空间快速增长时,下一个extent的单位值将以有规律间隔翻倍;可以明确,这就是表每分配extent16次新的extent。
2. 随后的因素导致大量的小extents产生,持续后可引发extent溢出
·不合理的extent容量设置
每个表有一个下一个extent容量大小的定义,如果下一个extent对于表的增长率来说设定的太小,那么表很可能分配出大量的小extent。
· 不合理表空间chunk缝隙片
如果表驻留的表空间内没有一个完整的连续的空间,表空间chunk中只有一些小缝隙片,几个缝隙可能才满足一个新的extents的分配请求,那么一个小缝隙片视作一个extent。但是,这将不可避免导致extents数量上升过多。
通常,不合理的extent容量大小设置和不合理表空间chunk缝隙片决定了extent的增长率。
3. extents数量上限限定值
1个表允许的最大extents限定数值与操作系统中关于page的定义相关。一般意义上,可以参考下表内的数值,当抵达这些上限时,你必须重整表。
不同系统平台下Page大小和Extents数量
系统平台 | Page大小(KB) | 最大Extents数量限定值 |
HP, SUN, | 2 | 200 – 230 |
IBM, NT | 4 | 400 – 460 |
二、 Extents数量检查
1. 监控表extents的数量
l 表的extent数量查询
使用oncheck -pt <dbname>:<tabname>来检查是否是真有的那样多个extent。
l 表的extent分配明细查询
在informix的sysmasters库中,通过执行
select count(*) from sysextends where tabname="表名"
表sysextend记录了各个表每个段的大小和地址信息。
2. 识别extents数量过高的表
你可以在dbaccess中访问sysmaster库,查询表extent的数量。
select dbsname,tabname,
count(*) num_of_extents,
sum( pe_size ) total_size
from systabnames,sysptnext
where partnum = pe_partnum
group by 1, 2
order by 3 desc,4 desc;
close database;
...
三、 Extents管理总结
如果你避免了extent的溢出也就避免了你的informix数据库的非计划停机。一个informix表你不必定期重整它,但当extents过大时可能是重整它的一个好的理由。你可以按照以下例子修改extents大小的设定:
create table aaa(
.....
.....
) EXTEND SIZE 256000 NEXT SIZE 10000;
这样我一开始就把该表的初始空间增加为256M,申请空间为100M。重整以后extents的数量将减少,重整以后效果参见下图。
extent重整效果示意图