【Oracle】记录一次数据库连接池性能瓶颈问题

背景：

项目遇到一个

 

参考：

https://www.cnblogs.com/grefr/p/5046326.html

https://www.cnblogs.com/yx007/p/13177924.html

https://blog.csdn.net/zy_crazy_code/article/details/77855086

https://www.cnblogs.com/DBA-Ivan/p/9957923.html

 

Oracle中的连接和会话

 

1.  概念不同：概念不同：
　　连接是指物理的网络连接。
　　在已建立的连接上，建立客户端与oracle的会话，以后客户端与oracle的交互都在一个会话环境中进行。
2.   关系是多对多：
　　一个连接上可以建立0个，1个，2个，多个会话。
　　Oracle允许存在这样的会话，就是失去了物理连接的会话。
3.      概念应用：概念应用：
　　oracle的sessions参数决定的是会话数而不是物理连接数。
　　oracle的临时表中的数据是各会话间隔离的，而与连接概念无关。
　　jdbc的connection，对oracle是一个会话的概念。

4.    实际应用：
　　连接池，为了提高数据库交互效率，一般驱动程序都有连接池概念的实现。
  　　Oracle不同的驱动提供两种连接池概念。

　　一种译为隐式连接缓冲： 隐式连接缓冲在第一次getconnection（）时将根据配置初始化连接，并在每一个连接上建立一个会话。然后从这些会话中返回一个给本次调用。以后如果在本次connection.close()前调用getconnection（），将肯定得到另外一个会话。如果初始时建立的会话不够了，那么将新建物理连接，并在连接上建立一个会话。当然不能超过两个限制：1.MaxLimit【见程序，限制物理连接数】。2.sessions【oracle参数】。每次close()并不关闭实际的会话，而是返回连接缓冲中，供另一个getconnection()使用。所以可以得知，如果一个getconnection()中给某一个会话级临时表插入数据，然后close(),那么之后如果这个会话被重新得到，是可以看到插入的数据的。

　　一种译为OCI连接池：OCI连接池在第一次getconnection（）时将根据配置初始化连接，并在每一个连接上建立一个会话。注意，连接上一旦建立了一个会话，这个连接将还可以再建会话。那么在此时，会任取一个建完会话的物理连接再建一个会话返回。当然这时也要受限于sessions设置。对于OCI连接池，每一个connection.close()都将实际关闭会话，但物理连接保留。所以可以得知，如果一个getconnection()中给某一个会话级临时表插入数据，然后close(),那么此数据将被删除。

 

5．关于专用服务器模式下processes参数
            对于隐式连接缓冲，每一个连接上建立一个会话，对于每一个会话都将对应一个dedicated process。
            对于OCI连接池，只有物理连接上建立的那个会话才对应一个dedicated process(这里记为DP_A,DP_B)。而其他会话对应一个PSUEDO process.这是一个轻量级process，它是不算processes数的。
        所以关于这个问题“专用服务器模式是一个物理连接对应一个process，还是一个会话对应一个process？”，从这里可以理解oracle的设计思路确实一个是会话对应一个process，与物理连接不相关。但是实际的实现呢？当oci获得的connection上执行sql时，ORCLED的响应还是会借助到DP_A,DP_B上，如果DP_A,DP_B正忙，那就得一样地等。

 

 

分析案例：

https://blog.csdn.net/shy_snow/article/details/90703520

https://www.cnblogs.com/kerrycode/p/3636992.html