博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
informix插入数据报271,136错误
阅读量:2452 次
发布时间:2019-05-10

本文共 2224 字,大约阅读时间需要 7 分钟。

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

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

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

>

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

大家最后找到了原因:

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

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

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

你可能感兴趣的文章
python概率编程_Python中的概率编程
查看>>
Python中的运算符和表达式
查看>>
读写csv文件python_用Python读写CSV文件
查看>>
python super_使用Python super()增强您的课程
查看>>
愚人节导入_愚人节Python恶作剧
查看>>
正则表达式科学计数法_数据科学家的正则表达式
查看>>
sql基础_SQL基础
查看>>
一个工作表可以有两个事件吗_你有两个工作
查看>>
Raul的新机器学习书!
查看>>
python制作可视化图表_可视化数据–用python覆盖图表
查看>>
双耳节拍 枕头_枕头3-0-0不在
查看>>
输入/help获取更多指令_更多HTTP / 2新闻
查看>>
rodeo python_Rodeo 1.0:台式机上的Python IDE
查看>>
MongoDB和Python简介
查看>>
django 认证_Django中的LinkedIn社会认证
查看>>
上海流浪汉沈_Windows上的流浪汉
查看>>
2016年12月14日的安全链接垃圾邮件
查看>>
535cf_CF对象存储
查看>>
命题逻辑真值表_命题逻辑
查看>>
openbsd_OpenBSD对psutil的支持
查看>>