Informix锁表产生的原因,要么是多个用户同时访问数据库导致该问题,要么是因为某个进程死了以后资源未释放导致的。如果是前一种情况,可以考虑将 数据库表的锁级别改为行锁,来减少撞锁的机会;或在应用程序中,用set lock mode wait 3这样的语句,在撞锁后等待若干秒重试。如果是后一种情况,可以在数据库端用onstat -g ses/onstat -g sql/onstat -k等命令找出锁表的进程,用onmode -z命令结束进程;如果不行,就需要重新启动数据库来释放资源。
1:$ onstat -k | grep HDR+X
根据sessid得到进程pid,其中pid 是与此会话的前端关联的进程标识。
(可通过$ onstat -g sql sessid 命令查看执行的sql语句) 3:$ ps -ef |grep pid 由此,我们可得到锁表的进程,可根据实际锁表进程的重要程度的具体情况采取相映处理方法:
对于重要且该进程可以自动重联数据库的进程,可以用onmode -z sesid 的方法杀掉锁表session:
$ onmode –z sessid 否则也可直接杀掉锁表的进程 kill pid:
$ kill -9 pid 至此,死锁即被清除掉。 ————————————————————————- 查找锁定的表名称 通过onstat -k 查找的rowid 等于0的表锁信息的 tblsnum 信息查找表名。
如 tblsnum等于500e19 执行 select * from systables where hex(partnum)=’0×00500e19′ 查找到当前锁表的表名。 Informix -244 错误 : Could not do a physical-order read to fetch next row. 具体错误解释: #finderr -244 原因: a.锁表 b.记录太多 c.页损坏 d.某个进程死了以后资源未释放导致 在数据库端用 onstat –g ses/onstat –g sql / Onstat –k 等找出锁表进程,用onmode –z结束该进程, 不行,重启数据库释放。 锁方式: 行方式(row),页方式(默认page),表方式(table)。 解决: 1.降低锁级别 2.减少加锁事务的时间跨度 3.设置等待解琐时间 相关命令: )检查索引及页损坏情况 #oncheck –cID database_name:table_name ) 查看锁级别 #oncheck –pt database_name:table_name )设置锁级别(行方式) #alter table table_name lock mode(row) )设置隔离级别 #set isolation to dirty read )设置等待解锁时间(不宜过大) #set lock mode to wait second(秒) 不等待 #set lock mode to not wait
还可以这样解决:
如果是日志型数据库,在执行的时候,可以先锁定
begin work;
lock table tab_name in exclusive mode;
要执行的sql语句;
commit work;
如果是非日志的数据
lock table table_name in exclusive mode;
要执行的sql语句;
unlock table tab_name;
中间件全局事务锁问题
中间件与informix连接时会出现onstat -k 中 owner 内容为0的现象。
这是应该查看全局事务onstat -x 和onstat -G
DATABASE sysmaster;
select hex(tx_addr) trans_addr,hex(tx_lklist) lock_addr from systrans
where hex(tx_addr) like '%c00000006e329778%';
需要说明的是,c000000007674c58是使用onstat -x 或 onstat -G得到的全局事务的地址。
上面SQL语句提供出该全局事务对应的锁地址,这时如果得到的锁地址与锁表的锁地址相同的话,
你就必需从应用端(通常是三层结构的中间件)发命令让该全局事务回滚或提交,否则该锁会被一直持有,直到你执行oninit。
onstat -k 的owner 列中的地址与onstat -x 中的userthread 对应。地址: http://www.timetoyou.com/tag/informix%E6%9F%A5%E7%9C%8B%E6%AD%BB%E9%94%81%E7%9A%84sql%E8%AF%AD%E5%8F%A5 标签:name,锁表,死锁,Informix,sql,进程,table,onstat From: https://www.cnblogs.com/sucretan2010/p/17359794.html