记一次oracle 监听器 listen故障

最近看了一部《萨利机长》,讲的是40年经验飞行员的萨利,驾驶空客A320,在双发引擎全部失效的情况下,只用了208秒,把客机安全迫降在了哈德深河上的故事。


2017-02-17  下午,MES系统数据库监听器故障,导致MES系统失效的那一刹那,我觉得我同萨利遭遇了一样的处境。


MES 数据库 :ORACLE 11.1.0.7.0   NOARCHIVELOG模式  安装在WIN2008 R2上。

我接手时已经稳定运行大半年,一直没有什么问题。


周五中午,突然监听器 listener 无法连接,LSNRCTL status 报错:

TNS-12541

TNS-12560

TNS-00511

64-bit windows error:61:unknown error


观察到WINDOWS服务中,LISTENER服务启动和停止都是正常的,但就是不能连接。


但凡LISTENER监听器报错,很多会同配置有关系,什么IP呀,主机名称呀。

这种错误在初装数据库时候很多发生,但是我们的数据库已经稳定运行了一年,网络连接提示上一次重启服务器是211天前。

就我本人非常鄙视oracle的LISTENER相关的技术设置,极其难用,手工配置很多,导致故障点很多。而SQLServer就比它好很多。


而我之前的经验,都是在不断尝试中解决问题,但这个数据库不允许你去尝试,因为配置已经固定,改动会影响ROCKWELL应用服务器连接,没有完全搞懂的化还会引出更多的问题。


要在配置完全不动的情况下,解决问题,这个是一个隐形的前提。


我们先选择重启动了一次服务器硬件,结果现场硬件同事说服务器警告灯亮。我们一开始判断可能因为磁盘故障导致执行程序异常。

这个时候,我们开始准备做数据库的备份恢复准备。

1、确认昨天的备份数据有,

2、确认虚拟机主机备份有,

3、有条件就把当前的数据库EXP备份出来,还原到虚拟机中,来完全恢复满血复活。


因为数据库启动校验,加上情况汇报,再次登陆数据库时,我们过去了一个小时的时间。


2017-02-17  16:00 目前的情况是:

数据库正常,数据正在EXP备份,全程用时会是50分钟。

X3650 M4服务器通过网管口登陆查看硬件,一切正常。

数据库监听器 listener还是报一样的错误,监听无效。


因为数据库在备份中,我们又有了一些时间,来查询解决问题。

现在查询问题基本只能在百度上查,百度的广告做得很好,但是对技术资料的收集和google相比完全差太多。

一篇文章中提到,listener程序会有日志产生,位置在ORACLE HOME\listener\trace目录中,我按这个目录去找,苦苦的没有找到。

然后又检索了一些信息,都不是很靠谱。


然后我们请DMS开发组介入,我的印象中李昕在oracle 的SQL上是强于我的,说不定他原来遇到过,但很可惜,他没有遇到过。

他同我的观点基本一致,在不能随意配置的情况下,这个listener很难搞。


我想到了 BASIS群中的,惜分飞,百度上有名的oracle专家。

我把环境和故障都描述给了他,让他帮忙分析一下应该从哪个角度去考虑问题,他让我从新安装监听程序去重新配置一下监听。

我意识到这个方向也不怎么靠谱,但同他交流的字里行间,我开始慢慢稳定我的情绪,因为2个小时过去了,压力确实很大,我估计我当时的血压是很高的。


在一次全盘大文件查找中,我看到了listener.log,  原来它不在oracle home里,而是在D:\app\Administrator\diag\tnslsnr\JCMESDATA\listener\trace 这个里面。

它的大小确是到了4GB。

关闭 listener服务,改名listener.log,启动listener服务,故障解除了。

再用命令:lsnrctl set log_status off  彻底关闭写日志文件。诛杀曹无伤 :)


在此感谢领导的交通工具安排,硬件同事现场处理,网络同事接通网关口帮助,惜分飞的立即回复,MES开发小组的帮助,DMS开发组的帮助

最后感谢我自己,让故障在下班前解决,MES系统又恢复了太平。。。
























已标记关键词 清除标记
相关推荐
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页