记一次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系统又恢复了太平。。。