ITPub博客

首页 > 数据库 > Oracle > TNS12519、ORA12519错误处理及参数processes的设置

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

原创 Oracle 作者:湖湘文化 时间:2014-01-09 10:45:07 0 删除 编辑
 

TNS12519ORA12519错误处理及参数processes的设置

1、现象

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

TNS-12519: TNS:no appropriate service handler found

ORA-12519

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

TNS-12519: TNS:no appropriate service handler found

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

Process  q0002 diedsee its trace file

Ksvcreateprocessq002 creation failed

2、分析

TNS12519ORA12519

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%以上都是前几天的,当天的进程数很少(另外一个节点的情况相反,这是怎么回事呢?是中间件等应用程序无限建立连接而不释放?);网上有资料说可以使用如下命令来杀掉这样的进程,但是没敢尝试(通常不会有问题,LocalNo只是远程连接的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、处理

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

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

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就不正常。目前应用都是通过weblogicwebsphere来连接数据库的,就拿weblogic来说,在独占模式下,一般来讲,连接数据库的session有多少,在weblogic 连接池里都设定好了,比方,设定50个,那么就有50session来连接数据,不管有没有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/,如需转载,请注明出处,否则将追究法律责任。

下一篇: 回家过年咯
请登录后发表评论 登录
全部评论

注册时间:2009-05-31

  • 博文量
    108
  • 访问量
    1523410