下午測試人員報告prplrforecast表不能for upadate了，問是不是這張表被鎖了。
通過以下sql查詢果然發現此表被鎖。
發現prplrforecast表果然被鎖。從machine結果看所表的sql是從應用伺服器caic16上發出的。
檢視sid=336的session在等待什麼。
從等待事件event的結果sql*net message from client來看，簡單判斷為是網路問題。就根據sid，seq# 把這個session給kill掉了。再次執行鎖表的sql，沒發有表被鎖。問題貌似解決。
第二天早上，測試人員讓幫忙檢視是否相同的表是否又被鎖了。執行鎖表的sql一看，果然是被鎖了。同樣是昨天那個應用的機器發出的sql，再次檢視等待事件，也跟昨天一樣。懷疑是開發人員的**有問題，找到開發人員跟蹤程式後果然發現有個連線池只open了，但沒有關閉。原來開發這段**的人開啟這個連線池後只是做了查詢，沒有關閉也就沒有鎖表的問題。但現在他增加了一些功能有update的操作，沒有仔細讀原來的**。也沒有關連線池。所以出現了鎖表的情況。
專案組有規定連線池開啟後一定要關閉，也有類似的**檢查工具。但時間長了就有些大意了，並不是每次提交測試的**都經過**走查工具檢查後再提交的。
總結此次鎖表的診斷結過程，發現自己的思維還不是很嚴謹。有時候會想當然的去解決一些事情。幸好是在測試環境發現的問題，要是在生產出現類似問題可就嚴重了。
Oracle 鎖表 鎖表查詢 結束鎖表程序
1.oracle 鎖表 lock table 表名字in exclusive mode 所記錄 select from 表名字 for update 2.oracle 鎖表查詢 selectb.owner,b.object name,a.session id,a.locked mode from v...
查詢鎖表物件
最初由 lawrencium 發布 我寫的指令碼，有點慢，將就著用吧 kill session語句 alter system kill session 50,492 以下幾個為相關表 select from v lock select from v sqlarea select from v ses...
informix 查詢 鎖表
在informix中查詢select，表有千百萬條資料，結構導致松鼠死掉，沒有理會！繼續在此表中查詢，但是一直查不出來，sql一直在執行。原來是上個select造成鎖表，導致這個查詢無法進行。1 查詢出執行select語句的sql onstat g sql grep select 4855470 s...