今天上班,突然收到通知说某个服务访问不正常,于是赶紧看了下该服务的cataline.out日志,发现是得不到另一个服务的返回值,于是查看对应的服务的日志,发现取不到连接资源,从而连接不上数据库。(一波三折,定位问题就是这么麻烦)
初步定位认为是该服务设置的连接池太小了,于是为了尽快恢复服务,就将服务重启以释放连接。一开始好了,可是没过几分钟服务又挂了,于是加大连接池的连接数,50加到100,过一会服务又挂了,拉人定位,然后加大连接池继续重启,100到200。过一会又挂了,这会不行了,不能再加大连接池了,这不理想也不能无限制加,于是让服务瘫着抓紧定位问题。
select count(*) from v$session where machine='主机名' and username='用户名';
查看从该服务器连接到数据库实例的连接数量,发现每台机器的连接数量都有700到800个连接,而服务的会话连接池最大也就200,两套服务重启了几次,总数量加起来大概也就这个值,说明服务重启并没有将之前的会话删掉,这个问题就很大了。很快会话连接数已经达到了数据库设置的会话连接上限,导致后续的连接数据库操作出现TNS报错,无法连接数据库。
这时有三种方法恢复数据库:
1、杀掉该数据库用户下的所以会话连接:
select 'alter system kill session '||sid','serial#|