一条细小的报警短信的处理(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,还是需要考虑一些相关的设置。

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

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-10-22

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Netkiller

hyperledger v1.0.5 区块链运维入门(一)

中国广东省深圳市龙华新区民治街道溪山美地 518131 +86 13113668890 <netkiller@msn.com>

59411
来自专栏北京马哥教育

Kubernetes网络部署方案

现在网络上流传很多Kubernetes的部署和搭建的文档,其中比较出名就是Kubernetes The Hard Way (https://github.com...

4518
来自专栏杨建荣的学习笔记

三封报警邮件的分析(r6笔记第95天)

今天收到3封报警邮件,从邮件内容中的报警情况来看,还是比较反常的。需要引起关注,找到原因处理。 这个库是一个历史库,库中的数据非常庞大,几十亿数据的表还是有好几...

2824
来自专栏杨建荣的学习笔记

一条执行4秒的sql语句导致的系统问题(r3笔记第10天)

一般来说一条sql语句执行个4秒钟是可以接受的,没有什么问题,但是如果应该执行1秒,却执行了4秒,问题就挺大的了。 今天查看数据库负载,发现在中午12:00 ...

3718
来自专栏coding

hexo搭建个人博客

搭建个人博客有很多种方式,最老牌的当属wordpress,功能丰富,但过于笨重。我想要的只是最简单的显示文章以及搜索功能,当然,样式要简洁漂亮,而且必须支持ma...

5917
来自专栏杨建荣的学习笔记

探究AWR 第二篇(r3笔记第93天)

在探究awr第一篇中介绍了awr的一些基本操作 http://blog.itpub.net/23718752/viewspace-1123134/ 在这一篇中,...

3187
来自专栏Netkiller

hyperledger v1.0.5 区块链运维入门

hyperledger v1.0.5 区块链运维入门 摘要 你网上搜索hyperledger大部分文章是讲解开发环境的安装与配置,没有一篇关于怎样运维区块链的文...

4978
来自专栏乐沙弥的世界

配置Oracle Gateway 12连接到SQL server 2014

最近的工作中需要基于Oracle连接到SQLserver2014,我们可以通过配置Gateway的方式来实现这个功能。这个Gateway的实质是透过dblink...

1472
来自专栏xingoo, 一个梦想做发明家的程序员

Oracle修改监听IP地址

oracle 11g断网安装时,没有检测net的功能,所以安装完后,netstat -an 发现自动监听的是127.0.0.1:1521,这样安装完成后,其他的...

1978
来自专栏杨建荣的学习笔记

11g备库无法开启ADG的原因分析 (r7笔记第62天)

今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果。 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在...

3844

扫码关注云+社区

领取腾讯云代金券