问题
在Informix数据库中，锁的使用和释放是自动完成的。但在某些异常情况下，当前台程序退出（正常或异常）后，相应在数据库中的会话没有终止，其占有的资源（主要是锁）没有被释放，影响了其他用户的使用。
这种情况可能出现在用户表或系统表中，一般都是由于产品的BUG或非常极端的情况引起的。
这时需要用手工的方式将有问题的会话终止，以释放其占有的资源，当然重新启动数据库自然就释放了所有的资源了，但有时业务上暂时不允许重新启动。
第一步，确定被锁住的资源
一般在遇到这种情况时，很容易确定被锁住的资源，如果是用户表，则一般会在操作这张表时报错，而如果是系统表，也会直接报告是哪张表，如：
211: Cannot read system catalog (sysprocplan).
144: ISAM error: key value locked
在以上的信息中，关于存储过程的系统表sysprocplan被锁住了。
在确定了相关表名后，需要查询出其在内部的表号，以便后续的处理，如下所示：
dbaccess <该表所在的数据库>
select hex(partnum) from systables where tabname="<表名>"
执行返回的是一个16进制表示的数，这是该表在IDS内部的标识。
第二步，查找上锁的用户线索
运行IDS锁的监控命令onstat -k，确定对该表上锁的用户线索，如下所示：
$ onstat -k
IBM Informix Dynamic Server Version 9.40.FC6 -- On-Line -- Up 18:13:12 -- 38912 Kbytes
Locks
address wtlist owner lklist type tblsnum rowid key#/bsiz
10a13a590 0 10afd30c8 0 HDR+S 100002 207 0
在输出中，查找tblsnum为第一步找到的表号的行，每行代表一个锁资源的情况，并找到相应的owner，即使用这个锁的用户线索号。
第三表，查找用户线索对应的会话
通过用户线索监控命令onstat -u进一步查找相应的会话以及用户情况。如下所示：
$ onstat -u
address flags sessid user tty wait tout locks nreads nwrites
10afd1028 ---P--D 1 informix - 0 0 0 28 7
10afd1850 ---P--F 0 informix - 0 0 0 0 0
10afd2078 ---P--- 5 informix - 0 0 0 0 0
10afd28a0 ---P--B 6 informix - 0 0 0 0 0
10afd30c8 Y--P--- 17 informix 4 10b1f9548 0 1 157 0
10afd4118 ---P--D 9 informix - 0 0 0 0 0
10afd4940 Y--P--D 13 informix - 10a125f10 0 0 0 0
其中第一列为线索号，相对应的第三列为拥有该线索的会话号。
第四步，分析原因并采取措施
有了会话号之后，就可以进一步分析原因或采取相应的措施了，如：
onstat -g ses <会话号>,分析会话的状态
onstat -g sql <会话号>,查看会话的SQL情况
注意，如果在会话的database一项中出现的是“－”，说明该会话所对应的客户端程序已经退出，但数据库中的会话并未终止，
或通过onmode -z <会话号>直接终止该会话，其所占有的锁资源将全部释放。
管理建议
- 请关注异常锁的情况，如果频繁出现，应该是产品的BUG，要考虑IDS版本的升级。