專案在運行程序中，偶現專案查詢時卡死在那里，但是確認過sql并無問題，后面記錄了幾天的日志，發現卡死的很有規律
下面是卡死的時間點：
2019-05-24 15:33:32
2019-05-24 14:34:05
2019-05-24 13:13:28
2019-05-24 10:43:28
2019-05-24 09:13:11
2019-05-24 08:33:22
2019-05-24 07:53:22
2019-05-24 05:53:13
2019-05-24 04:44:17
2019-05-24 04-03:07
2019-05-24 02:54:21
2019-05-24 01:53:21
2019-05-24 00:23:07
發現卡死時間大概都是在3分的時候，之前的幾天卡死時的時間也是類似，中間重啟過專案，但是卡死時間依然很湊巧是3分左右，資料庫中卡死后查詢時也找不到相關的死鎖，專案重啟后回復正常，查詢的卡死的表資料量也不大，每次最多幾十條資料。
求各位大佬可以指條明路，大概問題可能可能出在什么地方。
附上卡死時專案的jstack日志：
java.lang.Thread.State: RUNABLE
at java.net.SocketInputStream.sockerRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java :171)
at java.net.SocketInputStream.read(SocketInputStream.java :141)
at oracle.net.ns.Packet.receive(Packet.java:239)
at oracle.net.ns.DataPacket.receive(DataPacket.java:92)
每次在收包的時候會阻塞在那里,導致查詢不出來資料。
uj5u.com熱心網友回復：
這個要確定是資料庫卡死了，還是應用卡死了。當這個情況出現的時候，你把這條陳述句在 Oracle 客戶端中執行一下，看看是否能正常出結果。
uj5u.com熱心網友回復：
出現這個情況之后，在資料庫執行sql可以正常查詢得出結果，出現問題應該是很短的時間，應用未出現死鎖，記憶體泄漏這些情況，應該是資料庫卡死導致的。同樣的程式換個資料庫就一切正常了。
uj5u.com熱心網友回復：
最侄訓是未定位到卡死問題，查詢方法為單表條件查詢，很簡單的查詢，最終解決辦法是查詢那一步改為多執行緒查詢，使用執行緒輔助類CountDownLatch進行執行緒延時處理，保證回傳結果之后再繼續處理，就算其中一些時候查詢卡死，也不影響下一步的定時器查詢；再建一個監控類，監測卡死的查詢執行緒數，進行定時清理。該問題暫時這樣解決，專案運行兩周未出現問題。uj5u.com熱心網友回復：
如果是資料庫的問題，應該是遇到了特定查詢的執行計劃不理想的情況，有可能是由兩個功能導致的：1、ACS游標自適應，Oracle會隨著系結變數的值不同，自動調整SQL的執行計劃，這種情況下，撈出SQL來，將實際值帶入SQL再去執行看看它快慢其實是沒有意義的，要看的是當時它的實際執行計劃，可以通過AWR，或者dbms_xplan.display_cursor、 dbms_xplan.display_awr等方法去獲取當時可能的執行計劃；
2、cardinality feedback，基數反饋功能，隨著SQL中條件值的變化，SQL的執行計劃也可能發生變化
如果是這兩種情況，個人覺得還是應該研究下堵塞時候的SQL以及其查詢的表資料的情況，如果合適的話，可以嘗試使用提示來誘導CBO選擇固定的執行計劃看看能否避免這種問題。
uj5u.com熱心網友回復：
之所以說如果使用了系結變數，將實際值代入SQL再去跑沒有意義，是因為將系結變數替換為實際值，實際上這個SQL與使用系結變數的SQL，在文本上已經發生了變數，這根本就已經是兩個SQL，生成不同的執行計劃，跑出不同的性能是很正常的。
uj5u.com熱心網友回復：
之前也曾碰到這個問題,查的結果是此TABLE 有一個trigger 關系,請查一下是否如此uj5u.com熱心網友回復：
這是一個思路啊，也許還可能是JOB之類的，這樣的話，還需要抓下出問題時間段內的ASH報告比較好了
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/41710.html
標籤：開發
上一篇：sql優化問題