为何在往INFORMIX数据库中的某个表导入数据时报错?

jmbd 2006-01-11 09:05:42
我在往表business_info中LOAD数据时,导了一半,数据库报了两个错:
1、-- [Informix][Dynamic Server][group] SQL Error (-847) : Error in load file line 24435. [ ISAM error -136 : ISAM error: no more extents ]
2、-- [Informix][Dynamic Server][group] SQL Error (-271) : Could not insert new row into the table. [ ISAM error -136 : ISAM error: no more extents ]
顺便说一下这张表的结构,如下:
create table "cuser1".business_info
(
businessno varchar(40) not null ,
businesstype varchar(20),
businesssubtype varchar(20),
occurtype varchar(20),
businessstatus varchar(20),
businesstype1 varchar(20),
businesstype2 varchar(20),
businessattribute1 varchar(20),
businessattribute2 varchar(20),
businessattribute3 varchar(20),
businessattribute4 varchar(20),
applicantid varchar(40),
applicantname varchar(80),
applycurrency varchar(20),
applysum decimal(24,6),
applyprop decimal(24,6),
applytermyear integer,
applytermmonth integer,
applytermday integer,
applyratetype varchar(20),
applyfloattype varchar(20),
applyratefloat decimal(10,6),
applyrate decimal(10,6),
applypdgratio decimal(10,6),
applypdgsum decimal(24,6),
applypdgpaymethod varchar(20),
applymfeeratio decimal(10,6),
applymfeesum decimal(24,6),
applymfeepaymethod varchar(20),
applybailratio decimal(10,6),
applybailsum decimal(24,6),
applygp integer,
applypaytimes integer,
applypaycyc varchar(80),
applypurpose varchar(250),
planallocation varchar(250),
actualallocation varchar(250),
appdate varchar(20),
appsum decimal(24,6),
appprop decimal(24,6),
apptermyear integer,
apptermmonth integer,
apptermday integer,
appratetype varchar(20),
appfloattype varchar(20),
appratefloat decimal(10,6),
apprate decimal(10,6),
apppdgratio decimal(10,6),
apppdgsum decimal(24,6),
apppdgpaymethod varchar(20),
appmfeeratio decimal(10,6),
appmfeesum decimal(24,6),
appmfeepaymethod varchar(20),
appbailratio decimal(10,6),
appbailsum decimal(24,6),
appgp integer,
apppaytimes integer,
appcyc varchar(80),
fineratetype varchar(20),
finerate decimal(10,6),
actualpurpose varchar(250),
paysource varchar(250),
corpuspaymethod varchar(20),
interestpaymethod varchar(20),
creditaggreement varchar(40),
relativeagreement varchar(40),
signdate varchar(10),
contractno varchar(40),
loanaccount varchar(40),
bailaccount varchar(40),
contractputoutdate varchar(10),
actualputoutdate varchar(10),
contractmaturity varchar(10),
actualmaturity varchar(10),
actualfinishdate varchar(10),
finishtype varchar(20),
thirdparty varchar(80),
thirdpartyid varchar(40),
thirdpartyregion varchar(80),
warrantorid varchar(40),
vouchtype varchar(20),
vouchclass varchar(20),
guarantyrate decimal(10,6),
guarantyvalue decimal(24,6),
vouchfulfillment varchar(250),
vouchfulfillamount decimal(24,6),
legalcostsum decimal(24,6),
extendtimes integer,
lngotimes integer,
debtrecombinetimes integer,
riskrate decimal(10,6),
baseevaluateresult varchar(80),
bailbalance decimal(24,6),
pdgbalance decimal(24,6),
mfeebalance decimal(24,6),
legalcostbalance decimal(24,6),
putoutsum decimal(24,6),
balance decimal(24,6),
overduebalance decimal(24,6),
dullbalance decimal(24,6),
badbalance decimal(24,6),
interestbalance1 decimal(24,6),
interestbalance2 decimal(24,6),
finebalance decimal(24,6),
lastclassifyresult varchar(80),
lastclassifydate varchar(10),
amount1 decimal(24,6),
amount2 decimal(24,6),
amount3 decimal(24,6),
amount4 decimal(24,6),
amount5 decimal(24,6),
orgid varchar(40),
userid varchar(40),
badorgid varchar(40),
baduserid varchar(40),
pdassetdate varchar(10),
pdassetbalance decimal(24,6),
pdassetinte decimal(24,6),
duty1 varchar(80),
duty2 varchar(80),
duty3 varchar(80),
duty4 varchar(80),
finallyapporg varchar(20),
finallyappdate varchar(20),
inputdate varchar(10),
updatedate varchar(10),
finishdate varchar(10),
multiflag varchar(10),
remark varchar(250),
normalbalance decimal(24,6),
riskrange decimal(16,4),
vouchmarketval decimal(24,6),
edfvalue decimal(24,6),
lgdvalue decimal(24,6),
elvalue decimal(24,6),
signcontractno varchar(50),
contractserialno varchar(50),
approveid varchar(20),
checktype varchar(20),
primary key (businessno) constraint "cuser1".business_info_pk
) extent size 32 next size 32 lock mode page;
revoke all on "cuser1".business_info from "public";

create index "cuser1".b_info_i1 on "cuser1".business_info (multiflag);

create index "cuser1".business_info_i18 on "cuser1".business_info
(updatedate);
create index "cuser1".business_info_i19 on "cuser1".business_info
(balance);
create index "cuser1".business_info_i12 on "cuser1".business_info
(contractno);
create index "cuser1".business_info_i14 on "cuser1".business_info
(actualputoutdate);
create index "cuser1".business_info_i15 on "cuser1".business_info
(vouchtype);
create index "cuser1".business_info_i16 on "cuser1".business_info
(warrantorid);
create index "cuser1".business_info_i17 on "cuser1".business_info
(orgid);
create index "cuser1".business_info_i2 on "cuser1".business_info
(businesstype);
create index "cuser1".business_info_i11 on "cuser1".business_info
(applicantid);
create index "cuser1".business_info_i3 on "cuser1".business_info
(occurtype);
create index "cuser1".business_info_i4 on "cuser1".business_info
(businessstatus);
create index "cuser1".business_info_i5 on "cuser1".business_info
(businesstype1);
create index "cuser1".business_info_i6 on "cuser1".business_info
(businesstype2);
create index "cuser1".bs_info_ii1 on "cuser1".business_info (apptermmonth);

create index "xdrun".ix_business_inf1 on "cuser1".business_info
(contractserialno);
导入的数据有6万多条,存放在一个.txt文件中。但是我在往另外一张表中导更多的数据的时候,却没有发生这种现象,为何在导business_info这张表的时候发生这种现象,而且在DROP掉这张表想重新建的时候报了另外的错:

-- [Informix][Dynamic Server][group] SQL Error (-242) : Could not open database table (cuser1.business_info). [ ISAM error -113 : ISAM error: the file is locked. ]
这又是为何?
...全文
1138 6 打赏 收藏 转发到动态 举报
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
earthpea 2006-01-14
  • 打赏
  • 举报
回复
我的看法和楼上的差不多,将extent size 32 next size 32 lock mode page改到1024也许就会好的多了,然后你再根据数据实际的使用情况来进行调整吧。只是六万多条记录,没有说明每条记录有多长,不好判断,呵呵。

建索引也需要空间的,你去了索引空间就够,说明的也是同样的问题了。
novell6789 2006-01-14
  • 打赏
  • 举报
回复
它这个表结构明显是用dbschema倒出来的,设计人员要是懂这语法,就不会是32了。
而且它的索引...估计占的空间比表占的还大...无语中。

jmbd 2006-01-12
  • 打赏
  • 举报
回复
第一个报错我知道是表空间不够,但是另外有一张表跟这张表的空间都一样的,而且导入的数据是这个表的3-4倍,却没出问题,这是为何?而且我又给这张表增加了一倍的空间,导入还是报这个错,为何?
第二报错是因为lock的问题,但是我发现并不是表级锁,因为照样能对该表查询,删除,但就是不能DROP,我怀疑可能是页级锁的缘故。我已查到这个锁的进程了,但是苦于没有管理员的身份进去,杀不了。

呵呵,不过,后来过了会时间,发现这个进程没了,就DROP掉了,但是导入数据时还会报第一个错。后来我就DROP掉重新建,不过这次我没创建索引(本来这张表有很多索引),就可以正常导入了,所以,也可能跟索引有关系。

综合上述问题,我想请各位高手谈谈具体的原因,呵呵,给的分不多,希望大家见谅,下次给分多点
donwmufromdying 2006-01-12
  • 打赏
  • 举报
回复
都提示no more extents了!赶紧增加空间吧!!!
xsfh66 2006-01-12
  • 打赏
  • 举报
回复
分太少,回答第一个,informix中每个表的extent数是有上限的,当extent数达到上限,有表空间也不能分配更多的extent,只有把表重建,增大extent的size,对于你这张表,太恐怖,你建表使用size太小(32),肯定不一会就挂了,btw,这表谁设计的,拉出去。。。强烈要求相关人员提升设计水平。呵呵
novell6789 2006-01-11
  • 打赏
  • 举报
回复
查帮助啊!这些信息都有的。
第一个大意是无法扩展,可能是空间不够了,也可能是扩展的块数满了。
如果确认有足够的数据库空间,建表的时候就指定足够空间给它。
第二个,就是有用户正在用这张表,lock了嘛。杀掉那个进程就OK了。

1,195

社区成员

发帖
与我相关
我的任务
社区描述
其他数据库开发 Informix
社区管理员
  • Informix社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧