这个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号呢?
图片描述

  • 到了这一步,我们就可以上网去找资料了。

之前的问题分析原因,都是为了确定,如果我们要去网上查找资料,应该搜索什么?
很多问题都是因为定位不清晰,结果上去一顿瞎找,然后根据自己找的内容一顿乱猜,导致本来简单的问题复杂化。

引用这篇文章:http://blog.itpub.net/1267930...

这篇文章内写的比较清晰了,对于别人写过的东西,我就不重复写了,只把怎么引导大家判断这个问题的内容写出来,帮助大家分析问题。

这个Case最终采用了删除Listener.log之后,再启动,就没问题了,呵呵。


少放香菜
56 声望3 粉丝