一条细小的报警短信的处理（r6笔记第96天)

最近偶尔会收到一封报警短信，提示内容大体如下，

xxxx,trc_directory (TNS-1190),log_directory(TNS-1190)，Please check log for details

对于这个问题，看似是监听出了问题，但是根据同事的反馈说监听一切正常，而且从业务部门也从来没有得到任何反馈说系统的任何问题，所以问题就搁置了下来，但是昨天再次收到这个问题，

感觉还是需要来看一下，毕竟收到报警短信了，应该是什么地方达到了阀值，还是需要关注的。

于是登录到服务器上去看，服务器上是11g的库，用到了asm,所以是grid和oracle独立的两个用户。

查看tns的情况，

$ ps -ef|grep tns

root 85 2 0 2014 ? 00:00:00 [netns]

grid 3431 1 0 2014 ? 01:40:55 /home/U01/app/grid/11.2.3/bin/tnslsnr LISTENER -inherit

grid 15587 1 0 2014 ? 00:32:19 /home/U01/app/grid/11.2.3/bin/tnslsnr LISTENER_1526 -inherit

oracle 30419 30323 0 22:42 pts/0 00:00:00 grep tns

查看grid中的日志显示内容为，可以看到有警告，但是不确定是否有这个问题导致。

WARNING: Subscription for node down event still pending

21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0

21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=services)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * services * 0

WARNING: Subscription for node down event still pending

21-OCT-2015 14:36:13 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0

因为报错信息知道了TNS错误上所以自己的注意力就集中在了那上面，除此之外也没有发现有任何的警告。

这个时候求助于metalink，发现竟然有一篇很详细的文章介绍。

How To Disable Oracle Database Listener Alerts TNS-01190 In Enterprise Manager Cloud Control 12c to avoid the error "trc_directory (TNS-1190), log_directory (TNS-1190),. Please check log for details." (Doc ID 1399060.1)

那么这个时候来看这个问题似乎就是水到渠成了。

根据这个帖子的说法，还是因为agent在oracle用户下，而监听在grid下，所以agent需要周期性的去查找一下监听的信息的时候，因为没有权限，所以会有一些问题。

对于这个问题，如果通过EM来修正，就可以找到对应的监听

然后在 监听器->监视->度量和收集设置里面可以看到其实1190就是最高的阀值了。

这个时候一种解决办法就是把1190从这个阀值中去掉。

当然去掉之后，偶尔的报警短信一直到今天再也没有出现过。

不过这样处理问题还是治标不治本，知道还是因为一些设置的不规范，单纯修改阀值，去除阀值虽然可行，但是还是不够彻底。

所以继续开始琢磨改怎么处理。继续查看，发现了两篇相关的文章。

EM 11g: How To Prevent the Generation of The Listener Error TNS-1190 From the Enterprise Manager 11.1.0.1 Grid Control Console (文档 ID 1595086.1)

'WARNING: Subscription for node down event still pending' in Listener Log (Doc ID 372959.1)

第一篇虽然是11g中的解决方法，但是我觉得更加全面，因为里面提到了4中方法，第一种就是解决这个警告，因为这个也是间接反映了这个问题，第二种就是通过EM修改阀值，去掉1190的阀值

第三种是添加监听密码，但是这种似乎还是不太适用，第四种是直接忽略，好像也有道理，但是我不愿意这么做。

好了，这么看来，第二种已经做完了，那么目前的效果是怎么样的呢？

查看监听日志的情况

$ tail -f *.log

Thu Oct 22 22:53:44 2015

22-OCT-2015 22:53:44 * ping * 0

WARNING: Subscription for node down event still pending

22-OCT-2015 22:53:44 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0

可以看到监听的警告依然存在，那么就开始在listener.ora里面添加一个参数

SUBSCRIBE_FOR_NODE_DOWN_EVENT_LISTENER_1526=OFF

这个其实也是把一个类似的触发器关掉，可见oracle在这方面真实技高一筹。

修改完成之后，还是需要reload的。

$ lsnrctl reload listener_1526

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))

The command completed successfully

然后再次查看日志，发现就有了明显的变化。

Thu Oct 22 22:57:34 2015

22-OCT-2015 22:57:34 * ping * 0

WARNING: Subscription for node down event still pending

22-OCT-2015 22:57:34 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0

System parameter file is /home/U01/app/grid/11.2.3/network/admin/listener.ora

Trace information written to /home/U01/app/grid/diag/tnslsnr/rolequery/listener_1526/trace/ora_15587_139826913183488.trc

Trace level is currently 0

Log messages written to /home/U01/app/grid/diag/tnslsnr/rolequery/listener_1526/alert/log.xml

22-OCT-2015 22:57:37 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=grid))(COMMAND=reload)(ARGUMENTS=64)(SERVICE=listener_1526)(VERSION=186647296)) * reload * 0

然后日志中的警告就彻底消失了。

Thu Oct 22 22:58:44 2015

22-OCT-2015 22:58:44 * ping * 0

22-OCT-2015 22:58:44 * (CONNECT_DATA=(CID=(PROGRAM=)(HOST=test.com)(USER=oracle))(COMMAND=status)(ARGUMENTS=64)(SERVICE=(ADDRESS=(PROTOCOL=TCP)(HOST=test.com)(PORT=1526)))(VERSION=186647296)) * status * 0

按照这种情况，这个错误算是彻底解决了，修不修改阀值已经没那么重要了。

从这个简单的案例可以看出这个细小的报警短信还是能够折射出一些小的问题来，比如grid和oracle的分离，agent安装基于oracle用户，但是监听在grid,还是需要考虑一些相关的设置。

如果出现了问题，单纯修改阀值或者屏蔽监控，只是把问题给藏起来了，还是没有得到解决，所以问题处理也要做到表里如一。