背景

项目中应用程序有连接池配置到我们自己的Oracle RAC（以下简称本地库）和友商的Oracle RAC（简称友商库），均为11G。另外由于历史原因有一些需求需要本地库与友商库联合查询，为了实现联合查询，本地库有创建dblink到友商库。熟悉的朋友应该都知道dblink之前是存在SCN暴增Bug的，所以在后期的开发中我们一直尽量替换掉原有使用dblink写法的代码，久而久之时至今日，已经不清楚到底哪些程序使用了DBlink。今天友商工程师反馈友商库中我们的sessions太多了，让排查一下。

登录友商库排查

针对友商库，我这里有查询用户，尝试查询下gv$session发现也有查询权限，排查开始！

先统计下友商数据库的连接数情况，发现节点1sessions 2300，节点2sessions 1100，节点1连接数确实比较高，而且分布不均匀。

select inst_id,count(1) 
from gv$session
group by inst_id；

再统计下连接数分布情况，发现sessions确实大多数来源于我的服务器。

select machine,count(1) nums 
from gv$session
group by machine
order by nums desc;

但诡异的是，其中一多半sessions的machine都是本地库Oracle Rac两台主机，由于数据库不会主动访问友商库，这里判断这些sessions就是本地库到友商库的dblink连接，但具体dblink有哪些应用程序使用还不清楚。

考虑先查询一下session执行的sql：

select b.sql_text,b.sql_fulltext
from gv$session a, gv$sqlarea b
where a.sql_id = b.sql_id
and (a.machine = 'myoracledb1' or a.machine = 'myoracledb2');

然后拿sql去代码里搜索下看是否可以查到，由于我这里只有部分源码，搜索后无果。

摘录sql发给各组开发排查，无果。

求人不如靠自己啊，自己想办法查查来源吧！

关联本地库排查

在gv$session中，process列对应着客户端操作系统的进程号。

这样我就可以使用以下sql在友商库里查询到客户端操作系统进程号（即本地库服务器执行dblink连接的操作系统进程号）

select process 
from gv$session 
where machine = 'myoracledb1' or machine = 'myoracledb2');

将查询出的所有进程号复制出来，在本地库新建一个临时表feng将结果导入。

接下来在本地库进行查询，

因为oracle中的所有进程都会记录在v$process中，v$process中的SPID即oracle服务器操作系统进程号，v$process中的ADDR与v$session中的PADDR为对应关系，尝试写sql进行关联查询

select machine,count(1) nums from (SELECT SESS.INST_ID,
       SESS.USERNAME,
       SESS.STATUS,
       SESS.SCHEMANAME,
       SESS.OSUSER,
       SESS.MACHINE,
       SESS.PORT,
       SESS.SQL_ID,
       SESS.PREV_SQL_ID,
       SESS.PREV_EXEC_START
  FROM GV$SESSION SESS,
       (SELECT DISTINCT(ADDR) FROM FENG A, GV$PROCESS B WHERE A.PROCESS = B.SPID) ADDRTAB
 WHERE SESS.PADDR = ADDRTAB.ADDR ) zz group by zz.machine order by nums desc

即通过在友商库查询到本地库使用dblink的进程号，然后用这些进程号在本地库的v$process中与SPID匹配，获取到ADDR，再用这些ADDR去v$session与PADDR匹配结果，最中可以获取到这些session的信息。

结果出来，查看machine列，发现这些session绝大多数的客户端主机都来源于应用集群XX，可以定位到dblink用法的代码是在这里了（由于process与session为1对多的关系，所以查询结果可能会有一些偏差，但查询结果里的machine95%以上的记录都指向某一集群，一定不完全是巧合）。

验证

既然要把问题抛给开发，那还是确定一下比较好。

尝试轮起上面定位的应用集群，发现每重启一个节点，友商库中的session就会降低一些，同时猜测dblink连接只有当使用时才会创建，应用启动时即连接池初始化时并不会创建大量dblink连接。全部重启后发现结果与猜测一致。目前可以确定为dblink的使用者为此应用集群XX，将分析结果转给开发进行接下来的代码排查与修改。

连接数高的问题处理

1. DBLink 不均衡

处理问题前查看到所有dblink均连接到友商库的1节点，若将连接均衡到两个节点，则会降低1节点的连接数。

查看本地库dblink创建语句，发现没有添加loadbalance参数，遂重建dblink增加loadbalance参数，但经过观察问题未解决，dblink仍连接到友商库1节点，后续进行问题分析处理。

2. 调整连接池配置

分析得知此应用集群业务量不高，原本连接池设置为初始化与最大空闲连接均为50，经过测试后，将连接池初始化与最大空闲连接数均调整为10。

3. 人为KILLED导致

处理问题前经分析友商库中gv$session，发现有近一半dblink过去的连接状态都为KILLED，说明被手动杀过，经与友商工程师确认确实有人为杀过连接（杀连接的原因不得而知），但连接被杀掉后会重新发起新的连接，且被KILLED的连接并未真正释放，所以连接数也会增多一倍，经轮起应用集群后所有KILLED连接均已释放。