为什么informix数据库锁表重启后就坏了

应该将锁表的SQL语句合出来看看，看看能否优化

转：

锁表处理步骤：

1、onstat -ks|grep HDR+X //重查询是那个表被锁

address wtlist ownerlklist type tblsnum rowidkey#/bsiz

c1809510 0d656e774 c181cb3c HDR+X6002e1 2c602 0

需要关注lklist和type项，从上面来看tblsnum为6002e1（6292193十六进制转换成十进制）

的表被锁了。可以重查询是那个表被锁：

dbaccess ：select * from systables where partnum='6292193'得到

tabnamebasetab_mvpn

owner smpmml

partnum6292193

tabid 12813

rowsize464

ncols 61

nindexes 1

nrows 2984

created12/10/2002

version839843846

tabtypeT

locklevel R

npused 746

fextsize 16

nextsize 16

flags 0

2、onstat -u，将owner(address)为d656e774的线程找出来

address flags sessid user tty wait tout locks nreads nwrites

d656e774 Y--P--- 4261 smp20-d6ad2330 0180 9962016

3、onstat -g sql d656e774可以将这个线程执行过的sql语句打印出来。

4、只要用informix用户执行onmode-z sessid干掉线程

onmode-z 4261

重点说明：onstat -g ses sessid找个进程PID来,然后ps -ef|grep Pidkill -9 pid

在处理这些问题时还会遇到表被锁是因为该线程还没有执行完毕，此时就不能简单的 onmode -z杀线程

大的当然是assert断言ASF错误，俗称崩溃，一般是长事务，锁问题等，分析时间不够，必须尽快解决，但重启后长事务的回退可能是个痛苦过程。

其他的就是参数修改，比如换端口等

-244Could not do a physical-order read to fetch next row.

The database server cannot read the disk page that contains a row of a

table. Check the accompanying ISAM error code for more information. A

hardware problem might exist, or the table or index might have been corrupted.

If the query was using the dirty read isolation level, this error code may be

normal behavior caused by reading data that was in a temporarily inconsistent

state from a concurrent update on the same data.

Unless the ISAM error code or an operating-system message points to another

cause, run the oncheck utility (secheck with IBM Informix SE or tbcheck with

IBM Informix OnLine) to check and repair table and index.

---