历史版本11 :连接池满问题 返回文档
编辑时间:
内容长度:图片数:目录数:
修改原因:
1. 问题描述编辑
若日志报ORA-12519 TNS:no appropriate service handler found，是数据库连接失败的错误，12519错误是监听不能提供服务。
2. 原因编辑
原因是我们定义数据连接后，点击连接时，此时会用掉一个连接池中的一个连接。
而在定义数据集后，点击预览按钮，此时连接池就会分配连接，可能会使用之前那个连接（之前的连接已释放），或分配一个其他的连接或新建一个连接。
若此时连接池所有连接都已用完，就会报如下错误：
而在定义数据集后，点击预览按钮，此时连接池就会分配连接，可能会使用之前那个连接（之前的连接已释放），或分配一个其他的连接或新建一个连接。
若此时连接池所有连接都已用完，就会报如下错误：
当客户请求数据库连接时，首先是查看连接池中是否有空闲连接（指当前没有分配出去的连接）。
假如存在空闲连接，则把连接分配给用户，并作相应的处理（即标记该连接为正在使用，引用计数加1）。
假如没有空闲连接，则查看当前所开的连接数是不是已经达到maxConn（最大连接数），若没达到就重新创建一个连接给请求的客户；
若达到就按设定的maxWaitTime（最大等待时间）进行等待；
若等待maxWaitTime后，仍没有空闲连接，就抛出无空闲连接的异常给用户。
假如存在空闲连接，则把连接分配给用户，并作相应的处理（即标记该连接为正在使用，引用计数加1）。
假如没有空闲连接，则查看当前所开的连接数是不是已经达到maxConn（最大连接数），若没达到就重新创建一个连接给请求的客户；
若达到就按设定的maxWaitTime（最大等待时间）进行等待；
若等待maxWaitTime后，仍没有空闲连接，就抛出无空闲连接的异常给用户。
3. 解决方案编辑
若您在FR连接池属性的设置中，已将最大连接数设置得过大，还出现如上的报错，此时通常就是数据库进程（processes）达到上限导致的，可增大数据库中的连接数目来解决此问题。如下在数据库中修改最大连接数：
查看当前的连接数
select count(*) from V$process;
查看数据库允许的最大连接数
select value from V$parameter where name='processes';
修改最大连接数为1000
alter system set processes=1000 scope=spfile
重启数据库，再查询最大连接数，数字改变就表示已修改成功。
说明：当客户释放数据库连接时，先判定该连接的引用次数是否已超过规定值，假如超过就删除该连接，并判定当前连接池内总的连接数是否小于minConn（最小连接数），若小于就将连接池布满；假如没超过就将该连接标记为开放状态，可供再次复用。可看出正是这套策略保证了数据库连接的有效复用，避免频繁地建立、释放连接所带来的系统资源开销。