Informix數(shù)據(jù)庫釋放異常的鎖資源:
問題
在Informix數(shù)據(jù)庫中，鎖的使用和釋放是自動(dòng)完成的。但在某些異常情況下，當(dāng)前臺(tái)程序退出（正?；虍惓＃┖?，相應(yīng)在數(shù)據(jù)庫中的會(huì)話沒有終止，其占有的資源（主要是鎖）沒有被釋放，影響了其他用戶的使用。
這種情況可能出現(xiàn)在用戶表或系統(tǒng)表中，一般都是由于產(chǎn)品的BUG或非常極端的情況引起的。
這時(shí)需要用手工的方式將有問題的會(huì)話終止，以釋放其占有的資源，當(dāng)然重新啟動(dòng)數(shù)據(jù)庫自然就釋放了所有的資源了，但有時(shí)業(yè)務(wù)上暫時(shí)不允許重新啟動(dòng)。
第一步，確定被鎖住的資源
一般在遇到這種情況時(shí)，很容易確定被鎖住的資源，如果是用戶表，則一般會(huì)在操作這張表時(shí)報(bào)錯(cuò)，而如果是系統(tǒng)表，也會(huì)直接報(bào)告是哪張表，如：
211: Cannot read system catalog (sysprocplan).
144: ISAM error: key value locked
在以上的信息中，關(guān)于存儲(chǔ)過程的系統(tǒng)表sysprocplan被鎖住了。
在確定了相關(guān)表名后，需要查詢出其在內(nèi)部的表號(hào)，以便后續(xù)的處理，如下所示：
dbaccess <該表所在的數(shù)據(jù)庫>
select hex(partnum) from systables where tabname="<表名>"
執(zhí)行返回的是一個(gè)16進(jìn)制表示的數(shù)，這是該表在IDS內(nèi)部的標(biāo)識(shí)。
第二步，查找上鎖的用戶線索
運(yùn)行IDS鎖的監(jiān)控命令onstat -k，確定對(duì)該表上鎖的用戶線索，如下所示：
$ 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為第一步找到的表號(hào)的行，每行代表一個(gè)鎖資源的情況，并找到相應(yīng)的owner，即使用這個(gè)鎖的用戶線索號(hào)。
第三步，查找用戶線索對(duì)應(yīng)的會(huì)話
通過用戶線索監(jiān)控命令onstat -u進(jìn)一步查找相應(yīng)的會(huì)話以及用戶情況。如下所示：
$ 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
其中第一列為線索號(hào)，相對(duì)應(yīng)的第三列為擁有該線索的會(huì)話號(hào)。
第四步，分析原因并采取措施
有了會(huì)話號(hào)之后，就可以進(jìn)一步分析原因或采取相應(yīng)的措施了，如：
onstat -g ses <會(huì)話號(hào)>,分析會(huì)話的狀態(tài)
onstat -g sql <會(huì)話號(hào)>,查看會(huì)話的SQL情況
注意，如果在會(huì)話的database一項(xiàng)中出現(xiàn)的是“－”，說明該會(huì)話所對(duì)應(yīng)的客戶端程序已經(jīng)退出，但數(shù)據(jù)庫中的會(huì)話并未終止，
或通過onmode -z <會(huì)話號(hào)>直接終止該會(huì)話，其所占有的鎖資源將全部釋放。
問題
在Informix數(shù)據(jù)庫中，鎖的使用和釋放是自動(dòng)完成的。但在某些異常情況下，當(dāng)前臺(tái)程序退出（正?；虍惓＃┖?，相應(yīng)在數(shù)據(jù)庫中的會(huì)話沒有終止，其占有的資源（主要是鎖）沒有被釋放，影響了其他用戶的使用。
這種情況可能出現(xiàn)在用戶表或系統(tǒng)表中，一般都是由于產(chǎn)品的BUG或非常極端的情況引起的。
這時(shí)需要用手工的方式將有問題的會(huì)話終止，以釋放其占有的資源，當(dāng)然重新啟動(dòng)數(shù)據(jù)庫自然就釋放了所有的資源了，但有時(shí)業(yè)務(wù)上暫時(shí)不允許重新啟動(dòng)。
第一步，確定被鎖住的資源
一般在遇到這種情況時(shí)，很容易確定被鎖住的資源，如果是用戶表，則一般會(huì)在操作這張表時(shí)報(bào)錯(cuò)，而如果是系統(tǒng)表，也會(huì)直接報(bào)告是哪張表，如：
211: Cannot read system catalog (sysprocplan).
144: ISAM error: key value locked
在以上的信息中，關(guān)于存儲(chǔ)過程的系統(tǒng)表sysprocplan被鎖住了。
在確定了相關(guān)表名后，需要查詢出其在內(nèi)部的表號(hào)，以便后續(xù)的處理，如下所示：
dbaccess <該表所在的數(shù)據(jù)庫>
select hex(partnum) from systables where tabname="<表名>"
執(zhí)行返回的是一個(gè)16進(jìn)制表示的數(shù)，這是該表在IDS內(nèi)部的標(biāo)識(shí)。
第二步，查找上鎖的用戶線索
運(yùn)行IDS鎖的監(jiān)控命令onstat -k，確定對(duì)該表上鎖的用戶線索，如下所示：
$ 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為第一步找到的表號(hào)的行，每行代表一個(gè)鎖資源的情況，并找到相應(yīng)的owner，即使用這個(gè)鎖的用戶線索號(hào)。
第三步，查找用戶線索對(duì)應(yīng)的會(huì)話
通過用戶線索監(jiān)控命令onstat -u進(jìn)一步查找相應(yīng)的會(huì)話以及用戶情況。如下所示：
$ 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
其中第一列為線索號(hào)，相對(duì)應(yīng)的第三列為擁有該線索的會(huì)話號(hào)。
第四步，分析原因并采取措施
有了會(huì)話號(hào)之后，就可以進(jìn)一步分析原因或采取相應(yīng)的措施了，如：
onstat -g ses <會(huì)話號(hào)>,分析會(huì)話的狀態(tài)
onstat -g sql <會(huì)話號(hào)>,查看會(huì)話的SQL情況
注意，如果在會(huì)話的database一項(xiàng)中出現(xiàn)的是“－”，說明該會(huì)話所對(duì)應(yīng)的客戶端程序已經(jīng)退出，但數(shù)據(jù)庫中的會(huì)話并未終止，
或通過onmode -z <會(huì)話號(hào)>直接終止該會(huì)話，其所占有的鎖資源將全部釋放。