问题描述：

?

生产数据库（oracle）中的session数量超高（2500以上），严重影响该库的性能。

?

?

原因：weblogic的数据库连接池参数配置不符合目前XX应用程序的实际情况，调整weblogic配置参数后，问题

????????? 解决。

?

后续优化：采用线程池取代目前的多线程无限新建的操作。

?

具体问题分析如下：

?

问题定位：

?????? 1：查看v$session中的2000多个连接，大部分都是Inactive状态，即非活动的，而且都是JDBC调用。

从而猜测这些连接应该是应用程序调用了一次，执行完sql后没有关闭物理连接造成的。

?????? 2：通过v$session和v$sqlarea表查看v$session中logon_time集中的区间段内所执行的sql，最后定位到两条:

?????? select 1 from dual和insert XX_web…._log …..(这条具体sql忘了，就是XX系统记录操作日志的那条sql)

?????? 经过和开发人员的沟通从而定位到这条sql的调用时XX系统中的激活等相关接口的实现程序。

?

问题分析：

?????? XX系统的激活相关接口由于有些是大批量的调用，而且每一条都需要记录日志到数据库，为了保障效率，程序中

采用了多线程处理激活逻辑和记录日志操作。

?????? 查看了XX的相关代码，数据库操作都是走的appframe的统一连接获取和关闭操作，没有程序员自己新建数据库

连接和未关闭的情况。从而猜测是否是appframe框架自己的连接管理出了问题，随后跟踪代码发现appframe的数据库连接

close最终调用的是每个应用自己配置的数据库连接池的close，它自己并不关注底层的connection.close。而且该框架

的应用相当多，这块也很成熟了，应该没有问题，进而进行数据库连接池的问题排查。

?????? XX应用没有使用常见的DBCP连接池，而是采用了weblogic中间件提供的数据库连接池，查看weblogic的monitor

console,显示最高的连接数目2500，和在数据库中查看的session数目一致，但weblogic连接池配置的Maximum Capacity

（最大连接数量）为100，共6个server，也就是说连接池最大能容纳600个连接，为什么最高时会达到2500呢？想到四种可能：

1：weblogic的连接池bug或weblogic的监控台显示bug。2：连接池泄露（这个查看了leaked connection的个数，6个

server均显示0，基本排除该元因）。3：特殊的情况可以不受容量限制。4：weblogic故意的（因为它自己的监控台能查看到这

2000多个连接，证明这些连接肯定还是由它产生并可控）。

?

1和2基本不太考虑，这么牛的产品应该不会出现这种低级BUG。主要考虑3和4，随后仔细查看了weblogic的connection pool

的参数配置，配合oracle官方文档，突然发现有一个“Pinned-To-Thread”参数比较奇怪，名字中带线程，联想到XX应用程序

正是在多线程的情况下产生的问题，所以仔细研究了该参数的含义，该设置启用后，当application关闭connection后,connection

并不会回到connection pool,而是被keep在