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_idand 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