最近看了一部《萨利机长》，讲的是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服务器通过网管口登陆查看硬件，一切正常。
现在查询问题基本只能在百度上查，百度的广告做得很好，但是对技术资料的收集和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系统又恢复了太平。。。
