技术反馈无法通过sql developer,pl/sql developer等第三方工具连接到远程的数据库,可以通过sqlplus进入到命令交互窗口,且db正常running。查看资源状态,发现远程连接的VIP和LSNR资源异常,处于offline的状态。
客户截图如下
可以看到vip和lsnr资源都挂掉
因为lsnr依赖于vip。当vip异常,lsnr自然也会异常,所以定位分析为何到导致vip异常
查看日志信息。如下
1.节点1在12点09分的时候出现IP被撤回
Apr 2 12:09:48 xxxdb1 avahi-daemon[8097]: Withdrawing address record for 172.20.8.39 on eth0.
2.节点2在12点10分出现ip被撤回
Apr 2 12:10:51 xxxsdb2 avahi-daemon[8072]: Withdrawing address record for 172.20.8.40 on eth0.
3.节点1的在12点09分监听报错
2017-04-02 12:09:55
TNS-12560: TNS:protocol adapter error
TNS-00530: Protocol adapter error
Linux Error: 113: No route to host
4.节点2在12点10分监听报错
2017-04-02 12:10:58
TNS-12560: TNS:protocol adapter error
TNS-00530: Protocol adapter error
Linux Error: 113: No route to host
5.LNSR被强制offline
6.CRS检测网络发现异常
7.CRS强制VIP资源offline
2017-04-02 12:10:51.635: [ CRSAPP][1507961152]0CheckResource error for ora.xxxdb2.vip error code = 1
2017-04-02 12:10:51.638: [ CRSRES][1507961152]0In stateChanged, ora.xxxdb2.vip target is ONLINE
2017-04-02 12:10:51.638: [ CRSRES][1507961152]0ora.xxxdb2.vip on xxxsdb2 went OFFLINE unexpectedly
8:两个节点的vip报错,报错信息输入到日志
节点1:
checkIf: interface ech0 is down
ping to 3.3.3.254 via eth0 failed, rc = 1 (host=xxxdb1)
ping to 3.3.3.254 via eth0 failed, rc = 1 (host=xxxdb1)
Interface eth0 checked failed (host=xxxsdb1)
节点2:
checkIf: interface ech0 is down
ping to 3.3.3.254 via eth0 failed, rc = 1 (host=xxxsdb1)
ping to 3.3.3.254 via eth0 failed, rc = 1 (host=xxxdb1)
Interface eth0 checked failed (host=xxxdb1)
9:触发bug,把bug信息写入到alertt日志,发现大量的kill session。
总结:由于OS操作系统层面的网络异常,导致两台服务器上eth0网卡上的私网ip被撤回,进而导致集群CRS的ping操作失败,标记网络异常,然后强制VIP资源offline,和LSNR也offline。由于VIP的离线,触发了10G的Bug,从而导致两个节点的数据库日志出现了大量的kill session信息。
解决方案:
1:检查服务器网卡是否存在故障,做故障排查。
2:关于Bug,有两种方案:一是把oracle升级到10.2.0.5的修复版本,二是修改service_name,使用非默认的service_name。(由于此问题是因为网卡故障导致bug,所以选择未升级)