Informix杀掉死锁的方法和查看死锁的sql语句

Informix锁表产生的原因，要么是多个用户同时访问数据库导致该问题，要么是因为某个进程死了以后资源未释放导致的。如果是前一种情况，可以考虑将 数据库表的锁级别改为行锁，来减少撞锁的机会；或在应用程序中，用set lock mode wait 3这样的语句，在撞锁后等待若干秒重试。如果是后一种情况，可以在数据库端用onstat -g ses/onstat -g sql/onstat -k等命令找出锁表的进程，用onmode -z命令结束进程；如果不行，就需要重新启动数据库来释放资源。

                                             
1：$ onstat -k | grep HDR+X          

获得sessid，其中HDR+X 为排他锁，HDR 头，X 互斥 ，sessid 是会话标识符编号。

                    

2：$ onstat -g ses sessid
根据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