Windows下Oracle 11.2.0.1.0 Listener.log超过4G影响数据库监听启

warkiz 发布于2019-08-06 10:51 / 580人阅读

摘要：让开发人员测试网络是否正常开发经过测试命令，证明可以通，这代表网络是通的。那么这个时候，我们可以初步判定，是监听出了一些问题，导致外部的没办法连接到这个上了。这个最终采用了删除之后，再启动，就没问题了，呵呵。

这个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之后，再启动，就没问题了，呵呵。

专线服务超融合服务器超过100万Android玩家受到影响 linux 下usb数据监听 4g下webrtc卡顿 windows服务监听

文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。

转载请注明本文地址：https://www.ucloud.cn/yun/61149.html

Windows下Oracle 11.2.0.1.0 Listener.log超过4G影响数据库监听启

摘要：让开发人员测试网络是否正常开发经过测试命令，证明可以通，这代表网络是通的。那么这个时候，我们可以初步判定，是监听出了一些问题，导致外部的没办法连接到这个上了。这个最终采用了删除之后，再启动，就没问题了，呵呵。这个Case，在网上一找有很多案例和解决方法，解决思路无非都是这么几种，自己在之前也遇到过，昨天研发同事在公司群上说他们的oracle数据库连不上了，没判断出问题，初步打算重装。...

miya 2019-07-23 16:46 评论0 收藏0
DBASK问答集萃第三期

摘要：问答集萃接下来，我们分享本期整理出的问题和诊断总结，供大家参考学习，详细的诊断分析过程可以通过标题链接跳转到小程序中查看。诊断结论请先尝试收集系统数据字典统计信息。诊断结论一般后会出现这种情况，但是不会出现几百个的情况。引言近期我们在DBASK小程序增加了众多专栏，其中包括盖国强、杨廷琨、罗海雄、张乐奕、黄廷忠、崔华、熊军、李真旭、何剑敏等专家栏目，还有2019年6月SCN兼容性问题...

leap_frog 2019-07-23 17:53 评论0 收藏0
Oracle APEX 系列文章4：在阿里云上打造属于你自己的APEX完整开发环境 (安装XE, O

摘要：更多关于阿里云弹性公网的介绍请移步这里。你下载的版本可能比钢哥的高，不过安装步骤是一样的。总结至此，数据库的完整开发环境就搭建好了。在接下来的文章里，钢哥将带你做进一步的优化，敬请期待。本文是钢哥的Oracle APEX系列文章中的其中一篇，完整 Oracle APEX 系列文章如下： Oracle APEX 系列文章1：Oracle APEX, 让你秒变全栈开发的黑科技 Orac...

pepperwang 2019-07-25 14:17 评论0 收藏0
Oracle APEX 系列文章4：在阿里云上打造属于你自己的APEX完整开发环境 (安装XE, O

摘要：更多关于阿里云弹性公网的介绍请移步这里。你下载的版本可能比钢哥的高，不过安装步骤是一样的。总结至此，数据库的完整开发环境就搭建好了。在接下来的文章里，钢哥将带你做进一步的优化，敬请期待。本文是钢哥的Oracle APEX系列文章中的其中一篇，完整 Oracle APEX 系列文章如下： Oracle APEX 系列文章1：Oracle APEX, 让你秒变全栈开发的黑科技 Orac...

Harpsichord1207 2019-07-23 18:20 评论0 收藏0
Oracle APEX 系列文章4：在阿里云上打造属于你自己的APEX完整开发环境 (安装XE, O

摘要：更多关于阿里云弹性公网的介绍请移步这里。你下载的版本可能比钢哥的高，不过安装步骤是一样的。总结至此，数据库的完整开发环境就搭建好了。在接下来的文章里，钢哥将带你做进一步的优化，敬请期待。本文是钢哥的Oracle APEX系列文章中的其中一篇，完整 Oracle APEX 系列文章如下： Oracle APEX 系列文章1：Oracle APEX, 让你秒变全栈开发的黑科技 Orac...

lemon 2019-07-23 17:46 评论0 收藏0