Oracle数据库端口突然无法访问的分析(r12笔记第46天)

 最近碰到一个蛮有启发意义的案例。是数据库监听相关的,但是实际的原因却又出乎意料。

 问题的反馈受益于开发同学,一个开发同学在lync上找到我,说现在一个线上业务的数据库访问有些问题,想问问我是否有什么建议。大体了解了下,他们在使用一个非1521的端口,比如端口是1525,他们在业务端看到的错误信息类似下面的样子:

java.sql.SQLException: Io exception: The Network Adapter could not establish the connection
    这个问题让我有奇怪,因为这个时间段我们也没有做数据库维护的工作,带着疑问我登录到了这个环境,发现网络确实有一些卡顿,我还在安慰开发同事,是不是网络超时引起的,我再确认一下。

   登录到了系统端之后,数据库是可用的,连接数有近800多个,所以说业务应该没有收到什么大的影响,而这位开发同学反馈的1525端口访问有问题是怎么回事呢,我查看了监听器的情况,发现1525的监听端口竟然没开,这就有些奇怪了。难道是谁把这个监听器停了?

    显然不合理。所以我们需要查看日志来看看,这个端口是之前就没有开启还是有问题,因为数据库版本较老,是一个10gR2的库,就在$ORACLE_HOME/network/log下找到了日志,找到1525端口对应的日志,发现最近的日志竟然是下面的内容:

Started with pid=11954             
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.127.xxx)(PORT=1523)))          
Error listening on: (ADDRESS=(PROTOCOL=ipc)(PARTIAL=yes)(QUEUESIZE=1))                        
No longer listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.127.xxx)(PORT=1523)))
TNS-12549: TNS:operating system resource quota exceeded                                       
 TNS-12560: TNS:protocol adapter error                          
  TNS-00519: Operating system resource quota exceeded  
   Solaris Error: 28: No space left on device 
   这个问题就让我有些疑惑了,首先查看了下磁盘空间,这个分区下的空间使用率是80%左右,不大可能出现空间不够的情况。查看了inode的情况,也没有发现什么问题。怎么会有空间不够的情况呢,难道是oracle的监听有什么特别的设置,这个明显有些说不过去。

    然后就尝试手工启动,结果系统层面也迟迟没有响应,稍等了一会,还失败了,最后报出的错误还是空间不够。

    那么这个问题到底该怎么解释,我认真梳理了下df -k的全部结果,发现/var目录竟然满了,多么低级的一个错误,当然看到这里,问题的解决思路也一下子清晰起来。

     说千遍万遍,竟然是因为空间的问题,这个很不应该啊。为什么会有这种情况呢,系统层面应该是有一个调度任务去删除额外的空间,但是频率还是不高,就在这个间隙出了这个问题,我想看看到底是哪里的日志溢出了,很快就发现是/etc/adm下的日志。

     这个目录下的日志怎么会有这么多呢,我想起来前段时间启用了syslog的选项,一些系统层面的操作都能够记录在案,没想到没过多少时间,竟然把这个目录都撑满了。

    我对于这个问题的原因还是很感兴趣,毕竟手工删除,或者尽可能频繁的清理日志没有抓住问题的本质,我查看了一圈日志,发现监听成功启动之后,syslog里面的日志竟然生成非常频繁。

  几乎是一秒一条记录的速度,这个看起来明显不正常啊。

日志的内容类似下面的形式:

Apr xx 11:11:39 xxxx.com ipmon[17088]: [ID 702911 local0.warning]
11:11:38.740903 e1000g0 @0:1 b 10.127.xxxx -> 10.127.xxxx PR icmp len
20 84 icmp echo/0 IN  
几乎每秒一条的记录,这对于系统其实压力是潜在的,我就想这服务器都老态龙钟了,经不起这么折腾,但是通过这个日志该怎么分析原因呢。

 
首先使用telnet xxx 
1523这种方式的日志明显不是上面的输出,那么是不是连接到数据库的频率太高了呢,这个也不大可能,里面有icmp的字样,可以通过listener.log看到数据库中的连接频率远没有日志中那么频繁。这个信息该怎么解释呢,我就换了中思路,如果是我要尝试测试连接,会用哪些方式,除了telnet,ssh,还有一种很常见的就是Ping了。

    一想到这里,再来看看日志,还真有点意思,我找了台服务器,模拟了这个过程,发现日志就是这个样子的,所以我就初步定为了问题可能的原因,就是应用服务器没有关闭ping,导致了数据库端的日志量频繁生成,最后导致磁盘空间爆满。

    和系统的同学聊了下他们有针对性的进行了排查,还真找到一个脚本,确实在调用ping的操作。禁用之后,这个问题就基本解决了,而且想想我心里还更踏实些。

时间: 2024-10-23 08:53:48

Oracle数据库端口突然无法访问的分析(r12笔记第46天)的相关文章

Oracle数据库重启后密码失效的问题(r12笔记第91天)

  前几天,我和系统运维的同事处理一个看似诡异的问题,他找到我说应用服务器启动的时候报了DB的Error,但是错误信息有限,他也没法完全定位到错误的原因,所以就希望我来帮忙看看这个问题是怎么回事,怎么解决.    从应用服务启动的日志来看,错误信息是连接池的地方有了问题. Error: 2017-06-09 10:04:59 init connpool:one or more conn open error. Error: 2017-06-09 10:12:50 init connpool:on

假期前的数据库检查脚本之主备关系(r11笔记第46天)

   快过年了,很多系统都要进入最后的检查和复验阶段,一方面在节假日前,提前发现问题总比过节的时候发现要好.另一方面如果出现故障的时候能及时进行处理,这个时候我们就需要有一个尽可能全面的元数据收集.而且还有一点比较重要的就是工作交接,如果你临时有事,需要让同事来代劳,你得提供清晰易懂的信息给他们.    可能有的同学会觉得我们已经有了数据库监控,基本的性能分析,这个工作是不是就可以忽略了.监控只是标记状态,出现问题时候它没法帮你处理,还是需要人工介入,而人工介入尽可能全面的信息就是这些元数据了,

oracle数据库ORA-600 3020错误恢复思路分析

recover database 报ORA-600 3020  代码如下 复制代码 Recovery of Online Redo Log: Thread 1 Group 2 Seq 5729 Reading mem 0   Mem# 0: E:\ORACLE\ORADATA\YYGDB\REDO02.LOG Tue Aug 19 19:37:29 2014 Errors in file d:\oracle\diag\rdbms\yygdb\yygdb\trace\yygdb_pr0s_4296

oracle数据库报错ORA-00600[kjhn_post_ha_alert0-862]原因分析

数据库版本和平台信息 数据库版本为10.2.0.1版本,而且是32位的win 2003 sp2之上 ORACLE V10.2.0.1.0 - Production vsnsta=0 vsnsql=14 vsnxtr=3 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options Windows Server 20

一个ORA-00600问题的简单分析(r12笔记第18天)

  在前些天尝试使用sysbench来压测Oracle,没想到初战就不顺利,因为初始化几百万数据库,竟然一个小时过去了,一个表的数据都没有初始化好,这个可让我大大失望,所以我就强制清理了会话,把数据初始化流程给终止了.    今天想继续试试,看看能不能优化一些地方.但是刚开始跑初始化数据的脚本的时候,就抛出了一个ORA-00600的错误. 错误信息如下: Creating table 'sbtest1'... FATAL: OCIStmtExecute failed in drv_oracle.

MySQL频繁停库的问题分析(r12笔记第33天)

  最近也抽空帮一些网友解决一些问题,有些是Oracle,有些是MySQL,有时候虽然忙忙乎乎,但是解决问题之后还是很有成就感的.   今天来说一个蛮有意思的问题,听起来还很诡异.是一个网友向我咨询,看看能不能给出一些建议.当我看到日志,隐隐感觉这是一个bug的感觉. 详细的日志如下: 2017-04-13 16:25:29 40180 [Note] Server socket created on IP: '::'. 2017-04-13 16:25:29 40180 [Warning] St

Oracle闪回原理测试(三)(r12笔记第16天)

 对于Oracle的闪回,很多朋友也问过问,到底是怎么玩的?如果自己做过一些闪回数据库的操作,就会发现这个功能非常强悍.   Flashback DML的操作其实还蛮容易理解的,但是Flashback DDDL那可就是另外一个level了,我们大概了解一下MySQL里面的闪回就会发现,真要实现无缝的全闪回,确实有很多的细节和场景需要考虑.而Oracle作为一个成熟的商业软件,是不希望我们了解很多底层的细节的,用着好就行,所以如果你想得到一些闪回更细节的东西,这个渠道就非常的窄,我们之前也测试了两

MySQL主从不一致发现的细小问题分析(r12笔记第63天)

   今天和同事一起看了一个问题,她在一个主从环境中发现了数据不一致,存在主键冲突.     show slave status的报错信息大概是下面的样子. Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 0 failed executing transaction '0e454161-3169-11e7-98f6

《Oracle数据库性能优化方法论和最佳实践》——第2章 Oracle性能优化方法论的发展 2.1 基于局部命中率分析的优化方法论

第2章 Oracle性能优化方法论的发展 Oracle数据库在开发和使用过程中对数据库的性能优化极为重视,几乎在每个版本的更新中都会对可优化的数据库做出改善.不仅如此,Oracle数据库还会使用优化方法来指导性能优化,会不断推出新的性能优化方法论,并依据优化方法论持续完善其可观察的性能优化体系.从Oracle 6到现在的Oracle 12c,经历了Oracle 7.Oracle 8.Oracle 8i.Oracle 9i & R2.Oracle 10gR1 & R2.Oracle 11gR