TNS12519、ORA12519错误处理及参数processes的设置

 

TNS12519、ORA12519错误处理及参数processes的设置

1、现象

客户方应用程序连接oracle rac数据库指定的节点，报错：

TNS-12519: TNS:no appropriate service handler found

ORA-12519

检查数据库，发现集群正常，监听服务等也正常，但监听日志有报错：

TNS-12519: TNS:no appropriate service handler found

没多久告警日志出现报错：

Process  q0002 died，see its trace file

Ksvcreate：process（q002） creation failed

2、分析

TNS12519和ORA12519：

Oracle官方提示

ORA-12519: TNS:no appropriate service handler found
Cause: The listener could not find any available service handlers that are appropriate for the client connection.
Action: Run "lsnrctl services" to ensure that the instance(s) have registered with the listener, and are accepting connections.

凭经验可以判断告警日志出现的报错，是当前进程数已经达到参数processes设置的上限，不能创建新的进程了。

查看一下，验证：

select count(*) from v$process;

返回结果是799，当前数据库的processes参数设置值为800，看来不够用，需要调大。

进一步检查，发现数据库有很多是LOCAL=NO这样的进程，而且90%以上都是前几天的，当天的进程数很少（另外一个节点的情况相反，这是怎么回事呢？是中间件等应用程序无限建立连接而不释放？）；网上有资料说可以使用如下命令来杀掉这样的进程，但是没敢尝试（通常不会有问题，Local＝No只是远程连接的server process，但是如果远程的连接在做一些大量的磁盘操作，是不是直接杀了以后不会导致磁盘的问题就不是那么肯定了）：

ps -ef|grep -v grep|grep LOCAL=NO|awk '{print $2}'|xargs kill -9

还有发现有一个用户拥有600多个非活动的会话（应该是异常情况）：

select username,count(*) from v$session group by username;

3、处理

当时和客户商量，认为重启数据库动作较大，先试试杀掉之前查询到的那个用户所有的非活动会话，或者重启节点监听。尝试后，观察一段时间，没什么效果，进程数还是一直大。

后来，决定使用杀手锏，下班时间操作，调大参数processes为1000，暂停应用，重启数据库生效:

SQL> alter system set processes=1000 scope=spfile sid=’*’;

crs_stop -all

crs_start -all

4、建议

rac数据库负载均衡，客户应用程序连接数据库时目前使用的方式是直接指定虚ip和实例名，虽然数据库有好些应用，但是手工指定，目前的情况是两个节点负载情况严重不平衡，节点1的进程数不到100，节点2却达到了上限800。

5、结果

调大参数后，暂停应用，重启数据库，开启应用，测试，没有问题，搞定收工。

附： 网络搜到的一些参考资料

oracle连接常见的有带LOCAL=NO参数或带LOCAL=YES的进程。

LOCAL=NO：非本地连接，即网络连接。它是通过Listener 连接到服务器的。客户端的应用通过客户端的监听向服务器的监听发送请求，服务器的监听接收后，在与数据库连接，执行相关操作，在把结果返回给客户端。这是通过监听的流程。 所以在客户端需要配置监听，即配置tnsnames.ora。

LOCAL=YES：本地连接。 本地连接不走监听，所以在服务监听没有启动的情况下，通过本地的sqlplus 还是可以连上数据库的。

只要是通过SQL*Net网络远程连入的客户端程序都显示为LOCAL=NO

LOCAL=NO 这个表示，业务账户通过走监听连接到数据库，这个的多少要看数据库的设定PROCESSES上限是多少，再有的是，平时LOCAL=NO |wc -l 有多少，觉得不正常又是多少，可以设定一个基准线，比方说，session=500是正常的，如果session=600就不正常。目前应用都是通过weblogic或websphere来连接数据库的，就拿weblogic来说，在独占模式下，一般来讲，连接数据库的session有多少，在weblogic 连接池里都设定好了，比方，设定50个，那么就有50个session来连接数据，不管有没有ACTIVE SESSION,反正就占着位置，所有说，weblogic这样的应用服务器与数据库是密切相关的。一般有这样的故障，数据库session很高，但是基本上不活动，也就是说session僵死了，原因不在数据库，而至weblogic这一端，为什么了，因为weblgic应用服务器网络中断，或者weblogic服务器意外重启，导致数据库session死掉了，但是session却还占用processes数量，导致数据库session数量其高不下。这个时候要找应用的人来问了，问清楚了，就手动kill掉死掉的session，释放掉session资源，数据库短时间内是不会跟你清理的。
还有一种情况，在rac环境，应用连错节点导致session数据其高也是常有的事，这个时候，dba就需要介入了，告诉应用人员，你的应用时连节点1，而不是连节点2的。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/21256317/viewspace-1068646/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/21256317/viewspace-1068646/