上午项目经理反映数据库时好时不好。具体表现为：应用程序正常；客户端程序有时能连上，有时连不上（连不上时间居多），报错：“IO错误：The Network Adapter could not establish the connection”或“IO错误：Connection reset”。IP能ping通，无丢包。
环境说明：2节点rac，操作系统rhel6.5，数据库oracle11.2.0.4。scan ip在节点1。
测试网络连通性
同一网段内的其他服务器，分别ping public IP、VIP、scan IP，延迟均<1ms。telnet VIP和scan IP的1521端口，可以联通。
检查集群状态
正常。
检查监听状态
集群监听显示refused 0。
本地监听显示refused 0。
集群监听日志未发现异常。
本地监听正常。
alert日志
顺手查看alert日志，虽然感觉不大可能。无报错，相关时段内无任何输出。
连接数据库测试
在数据库服务器上连数据库（注，当时在节点1上测试，scan ip在节点1）。
继续网络测试
到此，感觉问题不在数据库，可能出在网络。
再次在客户端测试，只有第一次连上，其他全部连不上；更改连接串，直接指向节点1，能正常连上，测试多次都能连上；更改连接串，直接指向节点2，多次测试也能正常连上。好像问题出在scan ip。（未截图）
后台测试网络，一直ping VIP、scan IP，并用tcping测试VIP、scan IP的1521端口。10-20分钟后，查看结果：所有ping都正常，无丢包，平均延迟<1ms；VIP的1521端口正常，scan IP的1521端口偶尔正常，绝大多数时间都不通。（未截图）
回到数据库服务器（节点1），查看状态，处于listen状态。
登陆到节点2测试scan ip的1521端口，测试多次，全部不通。
现象汇总
① 节点1上连数据库正常，无论是通过scan ip还是直连某一个节点；
② 局域网内其他服务器直连某一个节点正常，通过scan ip不正常；
③ 数据库服务器public ip、vip、scan ip，ping都正常；
④ public ip、vip的1521端口正常，scan ip的1521端口不正常。
防火墙检查
怀疑是不是防火墙上做了限制。
检查本地防火墙，全部处于关闭状态。
和项目经理沟通，所有到数据库连接全部指向节点1，并向用户确认最近是否有动过防火墙。
不过在等待结果时，还是有疑惑：如果防火墙出问题，一般应该一直都是断的，不应该时好时不好。会不会是防火墙、交换机等硬件出故障了？还有，通过scan ip发起请求时，好像节点1根本没有任何响应，貌似包没有到达节点1。然后测试了22端口，居然也不通。仔细一测，scn ip的22端口不通，public ip、vip的22端口正常。而节点1的22端口是监听所有地址的。突然想到，会不会连scan ip时指向其他服务器了？
arp检查
查看arp信息，scan ip的mac地址和节点1上的public ip、vip的mac地址居然不相同！
和项目经理确认，用户是否有上新服务器占用了scan ip。
原因找到，问题解决
经过确认，新上线负载均衡，和scan ip冲突。
110地址（scan ip地址）被节点1和负载均衡相互抢，110指向的硬件是不固定的。
在节点1上连数据库，通过scan ip连，因scan ip在本地，不经过交换机，所以正常；因此节点1上连数据库会一直正常。
如果110指向节点1，则能正常连到数据库，否则失败。
如果110地址指向负载均衡设备，新发起的连接指向负载均衡，所以监听的refused为0。
已连上数据库的会话，实际的连接会分配给VIP，因2个VIP均正常，所以，已连上的会话只要不重连会一直保持正常。
必须做好IP地址规划和管理，哪些IP做什么用，哪些IP可用，必须有清晰的了解。
出故障，多数都是变动引起的，处理前询问做过的变动能更好协助处理问题。
dba需要掌握各种知识，存储、网络、操作系统等也要有一定了解。
