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