Informix 244问题求助

牵手

近期我遇到informix 244的问题，错误如下：
SQL statement error number -244.
Could not do a physical-order read to fetch next row.
SYSTEM error number -154.
ISAM error: Lock Timeout Expired
已经使用了以下的方法：
1、对服务器上所有的数据库做了统计更新；
2、将所有的页级锁改称了行级锁；
3、把联表查询改成了按照索引的逐笔查询；
再以上操作后，效率有所提升，但是效果不大，而且，碰到这个错误还跳出，而其他的服务器就没有问题，请教

牵手

各位大虾，有谁能够指点一下阿

yyiiasc

可能是锁资源不够你在做什么操作
嗯可在执行操作时通过onstat -k看看锁资源使用情况

牵手

锁资源足够，才有2百多个锁，共有10万个可以使用的

yyiiasc

你在做什么操作
嗯 onstat -p帖出来看看是不是有锁冲突

牵手

Informix Dynamic Server Version 7.31.UC5    -- On-Line -- Up 4 days 20:55:05 --s

Profile
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
8009736  2844997  714808982 98.88   614123   1116422  33009868 98.14

isamtot  open     start    read     write    rewrite  delete   commit   rollbk
304326033 19354419 41555892 131026084 5958290  391907   331043   2359224  19025

gp_read  gp_write gp_rewrt gp_del   gp_alloc gp_free  gp_curs
0        0        0        0        0        0        0

ovlock   ovuserthread ovbuff   usercpu  syscpu   numckpts flushes
0        0            0        48638.48 13620.27 731      2788

bufwaits lokwaits lockreqs deadlks  dltouts  ckpwaits compress seqscans
1622696  1243     1779062720 61       0        1801     684597   667278

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
938552   15325    4860328  5806638    13947
现在不是高峰期，可能看不出来什么，明天上午10点我再贴上来一份

yyiiasc

锁冲突导致的吧 deadlks 61
你是在做什么操作时报错的？
可能因为事务或其他原因导致访问数据失败
改改隔离方式试试 Set isolation to dirty read

olivejs

-154    ISAM错误: 锁定因超时而失效。

这个网络操作已被暂停，等待另一个数据库服务器的响应的时间已经超过了最长的等
待时间。INFORMIX-OnLine 动态服务器假定出现了分布的死锁，用户的需求在等待一
个其它系统中的某个用户锁定的资源，而那个用户在等待这个用户所拥有的某些东
西。滚回当前事务，在一段延时后重新运行。如果这个错误经常出现，要求OnLine管
理员调整死锁超时的时间间隔的长度。

如果一个显式的等待时间超时，也会返回这个错误代码；就是说，如果你有语句SET
LOCK MODE TO WAIT 3，你对某个锁定的需求被放在队列中超过3秒，那么该操作以这
个ISAM错误代码结束?

牵手

onstat -p的结果
dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached
2343970  2851989  67626052 96.53   58643    111553   2895960  97.98

isamtot  open     start    read     write    rewrite  delete   commit   rollbk
43624056 1390097  2380707  21539934 475723   21039    23255    209250   11

gp_read  gp_write gp_rewrt gp_del   gp_alloc gp_free  gp_curs
0        0        0        0        0        0        0

ovlock   ovuserthread ovbuff   usercpu  syscpu   numckpts flushes
0        0            0        5033.48  1425.64  61       224

bufwaits lokwaits lockreqs deadlks  dltouts  ckpwaits compress seqscans
137717   445      170182611 4        0        205      63592    67281

ixda-RA  idx-RA   da-RA    RA-pgsused lchwaits
32791    1855     1552317  1559388    2219

牵手

8 buffer LRU queue pairs                     priority levels
# f/m  pair total  % of    length     LOW   MED_LOW  MED_HIGH   HIGH
0 f     12472    98.9%    12330        1    11928      389       12
1 m               1.1%      142        0      141        1        0
2 F     12469    98.8%    12315        1    11924      375       15
3 m               1.2%      154        0      153        1        0
4 f     12479    98.7%    12322        1    11907      394       20
5 m               1.3%      157        0      156        1        0
6 f     12480    98.8%    12325        1    11911      394       19
7 m               1.2%      155        0      155        0        0
8 f     12477    98.6%    12298        1    11895      373       29
9 m               1.4%      179        0      179        0        0
10 f     12479    98.6%    12310        1    11919      367       23
11 m               1.4%      169        0      169        0        0
12 f     12475    98.6%    12306        1    11875      410       20
13 m               1.4%      169        0      168        1        0
14 f     12473    98.4%    12272        1    11856      390       25
15 m               1.6%      201        0      199        2        0
1326 dirty, 99804 queued, 100000 total, 131072 hash buckets, 4096 buffer size
start clean at 2% (of pair total) dirty, or 250 buffs dirty, stop at 1%
0 priority downgrades, 0 priority upgrades

CLEANERS设置成1，应该没有脏页的问题吧