informix插入数据报271，136错误

informix 导入一个表，每次到到一个地方的时候就报，271，136错误：

informix@tonykorn97:~/tmp> finderr 271
-271 Could not insert new row into the table.

This problem has many possible causes, including a locked table or a
full disk. Check the accompanying ISAM error code for more
information.

informix@tonykorn97:~/tmp> finderr 136
-136 ISAM error: no more extents.

The database server needs to add an extent to a table but cannot
do so. Either not enough disk space is available in the dbspace, or the
table has been given the maximum number of extents that is allowed. The
database server administrator can determine the cause as follows:

1. Determine the tblspace number for the table. It is the value in
the partnum column of the systables table for this table.

2. Convert the tblspace number to hexadecimal and extract its
most-significant 2 digits (the high-order byte). This chunk
number indicates where the table resides.

3. Use the tbstat or onstat utility -t option to find out disk
usage for this table. Note particularly the values reported for
npages (disk pages available), nused (disk pages used), and
nextns (number of extents).

If nused is less than npages, and nextns is large (over 200), the table
has too many extents. The upper limit of extents per table is between 200
and 50. The limit varies with the table definition and the
disk-page size in use. Reallocate the table using fewer, larger
extents. Unload the table data to a flat file. Drop the table.
Re-create the table, specifying a first-extent size sufficient to hold
all its current data and a next-extent size between one-fourth and
one-sixteenth its current size. Then reload the data into the table.

If nextns is small or the difference between npages and nused is less
than the size of the next-extent size for the table, not enough disk
space is available in the dbspace where the table resides. Use the
chunk number from step 2 and the ON-Monitor or ON-Monitor Chunks
display to determine the dbspace, then add a new chunk to that
dbspace.

informix@tonykorn97:~/tmp>

但是查看数据库也明明有空间！表的扩展块也都没有用呢！
当时键表的时候用的扩展块大小是最大的33554430K，（因为当时估计这个表的容量将特别大）

大家最后找到了原因：

是informix的限制，这个表的数据应该是当时达到了容量的限制。具体信息在下面ibm的链接上。

http://publib.boulder.ibm.com/epubs/html/29918930.html#rn-ud0011084631

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/312079/viewspace-245632/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/312079/viewspace-245632/