Oracle DBLink bug引發的故障（Session Hang Memory leak）

某政府客戶，近期不斷有資料庫效能問題。某日，應用維護人員請求DBA介入殺會話， 因業務辦理很不順暢。

首先看到有嚴重的阻塞：

從gv$session_blockers可以看出，被阻塞的會話有156個。業務基本上已經進行不下去了。

通過以下SQL查詢阻塞的源頭：

select distinct b.blocker_instance_id, b.blocker_sid, b.blocker_sess_serial# from gv$session_blockers b where not exists (select 1 from gv$session_blockers a where a.inst_id=b.blocker_instance_id

and a.sid=b.blocker_sid and a.sess_serial# = b.blocker_sess_serial#);

 

定位了阻塞的會話之後，在資料庫中kill掉會話，或者直接通過作業系統殺掉

定位作業系統程式編號：

Select spid from v$session s, v$process p where s.paddr = p.addr and s.sid = <查詢到的阻塞者的會話SID>

通過確認會話屬於客戶端會話之後，在作業系統層面進行kill

 

殺掉若干會話之後，阻塞情況有好轉。

接下來診斷為何會有如此之多的阻塞。檢視gv$session, 發現很多會話存在SQL*Net message froom dblink的等待事件

此類等待的會話有293個之多，而且均來自於JDBC客戶端。

通過gv$session_blockers檢視中的blocker_instance_id, blocker_sid, blocker_serial#查了幾個會話的等待，發現均是dblink。嘗試殺掉一個會話，直接通過alter system kill session，提示session marked for kill, 無奈，只好找到會話的程式編號，從作業系統層面殺掉了。

相關會話最終全部被kill掉，系統也恢復了正常。

從AWR報告分析，很多SQL是通過dblink去查詢其他資料庫， 大部分的阻塞，也與執行dblink相關查詢會話無法返回有關，會話hang住。這引起了我的思考。相關的SQL即使效能再糟糕，也不應當有如此之多的會話hang住，開始懷疑是Oracle的bug。搜尋MOS, 發現疑似bug: 17308789

從資料庫版本（客戶資料庫版本為11.2.0.3）， 客戶端是JDBC，故障現象是會話hang住這些方面來看，現象比較吻合。但是因為客戶資料庫在exadata之上，並無相關補丁。

最終給客戶建議：
1. 修改應用， 避免在JDBC客戶端中使用DBLINK。可以採用OGG等方式進行不同資料庫之間的資料互動。

2. 儘量優化相關SQL

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/8520577/viewspace-2713271/，如需轉載，請註明出處，否則將追究法律責任。