这个Case，在网上一找有很多案例和解决方法，解决思路无非都是这么几种，自己在之前也遇到过，昨天研发同事在公司群上说他们的oracle数据库连不上了，没判断出问题，初步打算重装。
重装操作系统、Oracle，对于之前在这台服务器上保存的资料来说，可能重装很easy，但是涉及到数据的整理，恢复，就比较耗时，我们这个case的出发点是能不能把不用做的工作别做？
- 问题简单描述
从开发人员反馈来看，就是数据库连接不上了，监听启动不起来，导致第三方数据库连接工具，如PLSQL之类的都没法连到这台DB上。然后就要重装，我也是醉醉的。。 - 让开发人员测试网络是否正常
开发经过测试Ping命令，证明可以Ping通，这代表网络是通的。 - 进一步观察
因为我平时都在现场，所以公司那边的网络环境跟我是不通的，没办法直接远程到服务器上去看，所以先管他们要了一下数据库的Alert日志。。但是开发说不知道11g的日志在哪。。。昨天找人看也没找到。。看来有必要先普及一下这部分。。
oracle 11g Alert日志的位置
oracle 11g之后，alert日志的位置发生了改变，如果不知道怎么找的话，最简单的方法就是用sys用户登陆数据库，然后执行select name,value From v$diag_info;
之后命令会呈现出来一些我们查询出来的结果，在结果里找：Default Trace File,这个结果后面跟的内容，就是alert日志存放的路径了。
- 观察alert日志
800多M的日志。翻了好一阵，终于在日志里面定位到出问题的时间点了，为周日下午13点53分，从alert日志中的表现上来看，日志内没有很严重的报错，但是在周日下午13点53分之后，就再也没有DB相关的操作了，取而代之的都是这一段代码：
Fatal NI connect error 12537, connecting to:
(LOCAL=NO)
VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Time: 08-8月 -2017 08:57:19
Tracing not turned on.
Tns error struct:
ns main err code: 12537
TNS-12537: TNS: 连接关闭
ns secondary err code: 12560
nt main err code: 0
nt secondary err code: 0
nt OS err code: 0
opiodr aborting process unknown ospid (6716) as a result of ORA-609
Tue Aug 08 08:57:29 2017
这个报错其实我也查了一下，在生产库上经常会有这个报错，不过都不太影响实际业务。但是这个Case里面，是问题时间点之后全是这个报错了，明显有点不正常。
那么这个时候，我们可以初步判定，是监听出了一些问题，导致外部的IP没办法连接到这个DB上了。
- 为什么会这样？
其实这个Case处理的方法很简单，主要是我们处理这个Case的思路，怎样去想到下面的环节呢？
首先我们联想一下这个Case发生的时间，周日下午13点53分之后，研发是周一早上来发现有问题的，那么从这里我们可以判断出来，问题时间点之后，是没人操作DB的，这样也就排除了人为操作的可能。
既然没人操作DB，又从上面的分析环节判断出，这个Case导致的问题是跟监听有关。那么Oracle内有一个监听日志，为什么不去看看它呢？也许这里面有有用的信息？
- 找到Listener.log
开发给了我一张图，从这个图里我们能看出来这么几个问题。
1.这个文件，是不是有点太大了？
2.如果这个文件一直在写的话，为什么最后修改时间，是8月6号呢？
- 到了这一步，我们就可以上网去找资料了。
之前的问题分析原因，都是为了确定，如果我们要去网上查找资料，应该搜索什么？
很多问题都是因为定位不清晰，结果上去一顿瞎找，然后根据自己找的内容一顿乱猜，导致本来简单的问题复杂化。
这篇文章内写的比较清晰了，对于别人写过的东西，我就不重复写了，只把怎么引导大家判断这个问题的内容写出来，帮助大家分析问题。
这个Case最终采用了删除Listener.log之后，再启动，就没问题了，呵呵。
