谈谈informix extent

archills

数据库中创建表与段的关系

我们有时在进行表插入操作时，出现了-25580的错误号，该错误的信息提示：
System error occurred in network function.
A system call has failed. For assistance, contact your system administrator or Informix Technical Support.

通过onstat -d查询数据库的空间还有足够的空间供数据库使用，但是为什么会出现如此的错误了，这时，想起今年3月份G市SMP的话单出现了同样的信息提示，是数据库的的段值（extend值）超出了数据库的最大数目限制227，需要把c200_log重新创建，但是需要手工增加该表的初始空间和初始新增空间的大小，即在创建该表的同时指定该表的初始空间和初始新增空间的大小，具体的语句表达形式为
create table c200_log(
useridentifier  char(20),
.........
) extend size ??? next sixe ???;
其中extend  size  指定的数据大小的大小为创建该表的初始空间的大小（单位为kbyte)
next  size  指定的数据大小的大小为当该表的初始空间使用完毕后数据库表需要向数据空间申请空间大小的初始值。
当创建表没有具体指定 extend size 和next sixe的值时，extend size 和next size的缺省值都为16kbyte，即初始空间和初始新增空间的大小为16k。
因为我们创建表时，没有指定初始空间和初始新增空间的大小，这时数据库就按照缺省初始空间的大小(16k)来分配，一旦初始空间使用完毕，这时数据库就按照初始新增空间的大小16k来向数据库申请，如果再次使用完毕，再次按照初始新增空间的大小（16k)来向数据库申请，连续申请了16次后，这时数据库就把申请空间加倍。申请空间的大小与申请次数的关系为：（该数据是根据数据库informix的技术资料并在G市州SDP的表上加以实际核实获得）
申请空间的大小= 初始新增空间的大小*2^（申请空间的次数  /   16  ），
这时给大家引入一个值  ： extend值---------我们称为段值   （extend值表示该表在数据库里占用的   连续空间   的数目，他的最大数目被数据库限制为227，而实际上数据库的技术资料里面说明数据库支持最大的段值为200，这样我们可以理解数据库对每个表而言，支持对该表的最大的段值建议不超过200，一旦超过该值，我们对数据空间就没有达到有效的利用，且同时影响数据库的查询效率，甚至就会出现申请空间失败的情况）。

这样大家可以理解以下的公式。在创建表时，段值（extend值）=1。
在每次申请空间时，段值可能会发生变化，变化的依据有以下几个条件：
1、当申请的空间与该表以前表空间在物理上存在连续块时，段值：=  当前段值  （没有变化）
2、当申请的空间与该表以前表空间在物理上不存在连续块时，段值：=  当前段值+1   ，段值增加1。  
3、当申请的空间与该表以前表空间在物理上存在连续块，但是这些物理上连续的表空间块一旦合并为一个段，将不包含于一个chunk (数据库保存数据的单位，一般我们定义为最大不能超过2GB---2048M）的空间块时，
段值：=  当前段值+1   ，段值增加1

这句话可以这样理解：如果一个当前段所包含的空间不是一个chunk的子集，段值加1。
有了以上的理解，加上数据库对段值（extend值）最大不能超过200的限制，我们来分析在缺省的情况下，数据库最坏会发生什么样的情况。
缺省情况下，数据库最坏的情况是：每次表申请空间与以前的表空间不存在连续关系（造成这样的原因可能是该表所在dbspace的其他表不断的申请或释放表空间的缘故）

这样造成  申请次数 = 段值的最大限制数目 =  227 。

最后一次申请的的空间 = 初始新增空间的大小*2^（申请空间的次数  /   16  ）
                                = 8*2^(227/16)=8*2^14=8*16384=131072（KBYTE)
                                =128M大小。
因为申请了227次空间，按照每16次番一番的规则，我们计算一下该表申请的总的空间大致为：
   16*8*（1+2+2^1+2^2+2^3+..........+2^14)=16*8*(2^15-1)
                                                =16*8*32767
                                                =4194176K
                                                =4G（BYTE）
也就是说在缺省最坏的情况下，数据库只能申请到4G的空间左右，4G的空间能保存多少数据量呢？
对于一个表而言，如果他的一条记录为280个字节的话（如果有索引，需要把索引考虑进去），他能保存的记录条数为
        1024*1024*1024*4/280=15339168=1550万左右的记录。
非常明了，在缺省最坏的情况下，informix只能给一个表分给4G的空间，即使你在数据库的用户下使用onstat -d  查看数据库还有足够的空间可以使用。因为我们被数据库的段值所限制住了。

这次发生的情况，c200_log表建立在workdbs上，因为该数据空间还有其他表，且这些表经常不断的增加删除数据等，所以这次c200_log又发生了这种情况，发生时，c200_log有2700多万条记录平均每条记录约300个字节。

情况并非这么坏。
以下将就谈谈一点建议和解答部分疑问。
1、如何查看一个表的段数目。
在informix的sysmasters库中，通过执行
   select count(*) from sysextends where tabname="表名"
表sysextend记录了各个表每个段的大小和地址信息。

2、建议我们在进行系统的需求分析时和工程安装前，需要对表有一个初始的数据量的估计，如果一个表确实将来有较大的数据量，且该表所在的dbs还有其他较多的表存在时，我们可以考虑是否一开始就把该表的EXTEND SIZE  、NEXT SIZE 设置比较大。
例：
  create table aaa(
                .....
                .....
        ) EXTEND SIZE 256000  NEXT SIZE 10000;
这样我一开始就把该表的初始空间增加为256M，申请空间为100M，这只是从技术上的角度看，实际中是否可以，需要在平时测试中加以论证。如果一个表的段多了对数据库的查询效率是有一定的影响。

mywg

这么大的表是不是可以单独使用一个自己的dbspace？

蓝色键盘

楼主的描述很好，也是负责任的。偶在此支持一下。

对于你的两个问题，偶解释一下。

1、如何查看一个表的段数目。
在informix的sysmasters库中，通过执行
select count(*) from sysextends where tabname="表名"
表sysextend记录了各个表每个段的大小和地址信息。

回答:偶给你一个sql你去执行，然后输出系统中所有表或者某个表的extent的字段个数。sql脚本如下：

1. 
   
2. dbaccess - -<<!
   
3. database sysmaster;
   
4. select dbsname,tabname,
   
5. count(*) num_of_extents,
   
6. sum( pe_size ) total_size
   
7. from systabnames,sysptnext
   
8. where partnum = pe_partnum
   
9. group by 1, 2
   
10. order by 3 desc,4 desc;
    
11. close database;
    
12. !
    

复制代码

2、建议我们在进行系统的需求分析时和工程安装前，需要对表有一个初始的数据量的估计，如果一个表确实将来有较大的数据量，且该表所在的dbs还有其他较多的表存在时，我们可以考虑是否一开始就把该表的EXTEND SIZE 、NEXT SIZE 设置比较大。

回答：这个建议非常好，一般的对表有一个初始的数据量的估计是很必要的。但是如果用户在初期没有意识到extent的重要性。并且当extent的数量增长到>;128左右的时候，数据库的性能会大幅下降，此时其它的优化措施带来的好处几乎看不到。对此，采用如下的措施来处理这种情况：
（1）、如果能够估计表的数据量极其增长，那么在crete table的时候，指定extent 和next size。是一种比较好的办法。
（2）、如果在数据库表已经存在大量数据的情况下发现extent太大，此种情况，备份数据，删除表结构，然后计算初始extent和扩展extent大小后，重新load数据。

ifx

create a cluster index

gz_sys

好经验，当对于建立index是否也要指定extend呢？

lianyong

顶一下啊，这篇为什么不设为精华？
害的我好找。。。。

nicolasch

这么好的文章怎么不加精呢？

liaosnet

写的很好~~特别是下面这段.

这样大家可以理解以下的公式。在创建表时，段值（extend值）=1。
在每次申请空间时，段值可能会发生变化，变化的依据有以下几个条件：
1、当申请的空间与该表以前表空间在物理上存在连续块时，段值：=  当前段值  （没有变化）
2、当申请的空间与该表以前表空间在物理上不存在连续块时，段值：=  当前段值+1   ，段值增加1。  
3、当申请的空间与该表以前表空间在物理上存在连续块，但是这些物理上连续的表空间块一旦合并为一个段，将不包含于一个chunk (数据库保存数据的单位，一般我们定义为最大不能超过2GB---2048M）的空间块时，
段值：=  当前段值+1   ，段值增加1

这句话可以这样理解：如果一个当前段所包含的空间不是一个chunk的子集，段值加1。
有了以上的理解，加上数据库对段值（extend值）最大不能超过200的限制，我们来分析在缺省的情况下，数据库最坏会发生什么样的情况。
缺省情况下，数据库最坏的情况是：每次表申请空间与以前的表空间不存在连续关系（造成这样的原因可能是该表所在dbspace的其他表不断的申请或释放表空间的缘故）

不过随着技术的发展...有些东东已经改变了不少...在10中使用大块模式,可以忽视next extent的大小,数据库自动扩展extent..而不单纯的增加extent的数量...

prefect

經典收藏了
dbspaces中還有個叫tabspaces的空間，用來記錄extent的信息，extent數量太多導致tabspaces用完也會產生 無法申請空間的情況。