标签:
在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 IBM Informix Dynamic Server Version 9.40.FC6 -- On-Line -- Up 18:20:47 -- 38912 Kbytes Userthreads
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 <会话号>直接终止该会话,其所占有的锁资源将全部释放。
http://www.ithao123.cn/content-7724355.html
标签:
原文地址:http://www.cnblogs.com/chen110xi/p/5727936.html