数据库间歇性失败 OERR: ORA-12519

ORA-12519: TNS: 没有找到适用的服务处理
OERR: ORA-12519 TNS:no appropriate service handler found 
== 客户端连接间歇性失败，报错ORA-12519 ==

Oracle客户端与服务器之间正常连接，但是会偶尔连接失败，在重新连接之后又能连上，也不是网络问题，总结为：连接间歇性失败。开始的时候考虑到Oracle或者客户端由没有休眠这种说法，查阅了相关的资料，发现一个问题。
庆幸程序将Oracle数据库原始的错误输出’ORA-12519:’

现象：数据库间歇性失败

有时候连接成功，对数据库的操作也会成功，但是有些时候的链接请求会被拒绝，自己的软件系统是属于，请求、响应式的，有时候会成功，有时候就会失败。最终查到了 OERR: ORA-12519 TNS:no appropriate service handler found错误，直译为：“ORA-12519: TNS: 没有找到适用的服务处理”。检查数据库配置并无明显异常；

原因

数据库连接池初始值设置少了，不够用，导致数链接在请求的时候不够用，但是链接又是正常的，所有第一个步骤就是将链接池的参数参数放大。使用常用的SQL工具即可，我自己使用的SQLPLUS。
我自己的是在程序等待连接池分配连接时就已经超过了程序内部设置的等待时间，所以需要扩展连接池的大小，实际与数据库服务器执行效率关系不大。（跟程序本身有关）

解决方案

可以先确认是不是真的是连接数不够用，可以使用一下语句，查询数据库自启动以来的最大并发数量：

--查询数据库自启动以来的最大并发数量
select * from v$license;
-- 对比show parameter processes 中查询到的processes参数

1. 查询自己数据库当前的链接池发小；

-- 查看数据库系统参数
show parameter processes  
-- 下图中的processes参数即为当前数据库的最大连接数

从上图中可以看出，我本地服务器的数据库连接池的大小为150，我需要将其扩大一些。

2. 修改数据库连接池的大小；

-- 将数据库连接池的电销秀爱为300
alter system set processes=300 scope=spfile;

修改字后还需要使用show parameter processes 语句查看一下是否修改，因为processes参数位静态参数，需要在重启数据库之后才会生效。

Oracle spfile就是动态参数文件，里面设置了Oracle 的各种参数。所谓的动态，
就是说你可以在不关闭数据库的情况下，更改数据库参数，记录在spfile里面。更改参数的时候，有4种scope选项，scope就是范围。

参数类型
scope=spfile	仅仅更改spfile里面的记载，不更改内存，也就是不立即生效，而是等下次数据库启动生效。
scope=memory	仅仅更改内存，不改spfile。也就是下次启动就失效了。有一些参数只允许用这种方法更改。
scope=both	内存和spfile都更改，不指定scope参数，等同于scope=both。

3. 重启数据库

-- 正常模式关闭数据库
shutdown normal
SQL> shutdown abort
ORACLE 例程已经关闭。
SQL> startup nomount
ORACLE 例程已经启动。

等待正常关闭之后再正常开启数据库。

扩展

数据库连接池的工作原理：

连接池基本的思想是在系统初始化的时候,将数据库连接作为对象存储在内存中,当用户需要访问数据库时,并非建立一个新的连接,而是从连接池中取出一个已建立的空闲连接对象。使用完毕后,用户也并非将连接关闭,而是将连接放回连接池中,以供下一个请求访问使用。而连接的建立、断开都由连接池自身来管理。同时,还可以通过设置连接池的参数来控制连接池中的初始连接数、连接的上下限数以及每个连接的最大使用次数、最大空闲时间等等。也可以通过其自身的管理机制来监视数据库连接的数量、使用情况等。

数据库连接池的最适合的大小：

实际情况查看该文，该文描述了连接池大小的实际测试情况。但是与本文不冲突，“最优的数据库连接池大小”旨在解决高并发时多进程之间共享时间片与连接等待之间做一个效率取舍。
连接数 = ((核心数 * 2) + 有效磁盘数)
按照这个公式，如果说你的服务器 CPU 是 4核 i7 的，连接池大小应该为 ((4 * 2) + 1) = 9。
按这个公式，你的4核i7数据库服务器的连接池大小应该为((4 * 2) + 1) = 9。取个整就算是是10吧。是不是觉得太小了？跑个性能测试试一下，我们保证它能轻松搞定3000用户以6000TPS的速率并发执行简单查询的场景。如果连接池大小超过10，你会看到响应时长开始增加，TPS开始下降。
《DB & 连接池的设置 》
《连接池的最优设置》
本质上一种是解决高并发的时的小路问题，一个是解决连接池现有连接数不够用的问题，不冲突。我自己的文章是在程序等待连接池分配连接时就已经超过了程序内部设置的等待时间，所以需要扩展连接池的大小，实际与执行效率关系不大。（跟程序本身有关）

ORACLE数据库启动和关闭的几种方式区别：
ORACLE数据库启动和关闭的几种方式区别