WAS集群系列(2):数据库连接低级错误——网络连接问题
环境
项目点 | 指标 |
WAS版本 | 7.0 |
应用服务器操作系统 | Windows 2008 |
应用服务器系统位数 | 64bit |
数据库服务器操作系统 | CentOS 5.6 |
数据库版本 | Oracle 11.0.2.1 |
今天搭建WAS集群后,发布应用程序包及启动均成功,但在测试数据库连接时提示,不成功,建议查看KVM日志。
于是到日志路径下查看相关日志(此处参考为D:IBMWebSphereAppServerprofilesAppSrv01logsserver1SystemOut.log),信息如下:
虽然这么冗长的日志信息,但问题锁定到第一行,“The Network Adapter could not establish the connectionDSRA0010E”,这个问题按理说是常规问题,但由于进行了一个下午的各种配置设置,脑袋有些晕了。看到这个问题后,整个思路都跑偏了。现在将其记录,引以为戒。
错误的思考:
1、看到“The Network Adapter”,肯定是网络问题,想到是不是WAS集群两台服务器网卡问题,进行对数据库服务器及集群服务器互相ping通测试,ping通状态正常;
2、查看WAS数据源配置信息,开始检查各节点服务,重启各节点服务及HTTP服务等等,有些碰运气的胡乱尝试了,这个结果就是我的思路被自己彻底弄乱了;
3、于是接下来,做了更可笑的事,查看WAS集群下配置信息,怀疑数据源连接问题,对数据源格式由原来的“jdbc:oracle:thin:@10.53.105.64:1521:hyl”改为“jdbc:oracle:thin:@(DESCRIPTION =(ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.53.105.64)(PORT =1521)))(CONNECT_DATA = (SERVICE_NAME =hyl)))”。这里想的是因为网络连接问题,怀疑可能是集群服务器无法完成连接,可能是解析出问题了,于是修改成完整格式。测试数据库连接,依旧不成功。这里问题就出现了,忽略了简单的问题,把问题越想越复杂化了。
更正后的思考:
其实由上面第一点开始,就有些跑偏了,ping通测试后,应该最先想到的就是去看下数据库监听起来没有。而我完全忽略了这点,原因很简单,因为这台数据库服务器之前连接着单节点的WAS,连接测试没有问题,也就笃定了监听没有问题。就这么小的地方,自己有没有亲自去验证,而引发问题的复杂化。当发现数据库监听没有起来时才意识到,问题出在了这里,原来是当停止单实例WAS时,数据库服务器被重启过,而且该服务器上的监听并没有设置自动启动。说来是如此的简单。于是我启动监听,将之前改动过的测试恢复回刚刚配置完成后的常规设置状态,WAS数据源测试连接,结果两节点测试连接通过。
小结:
1、处理问题时,正确的思路比胡乱的尝试重要,只有方向对了才会“药到病除”,否则可能会“火上浇油”,把自己思路都弄乱了。
2、在技术上,记住了“The Network Adapter couldnot establish…”出现时,切记ping测试后,检查监听状态,确认后再做进一步分析。
转自“深蓝的blog”