错误提示：Io 异常: The Network Adapter could not establish the connection
数据库服务器端环境：HPUX + Oracle9.2 （小机服务能力还是很强的，DB连接数约为300～400）
应用服务器端环境：Windows 2003 企业版 + Tomcat5.0.28
应用连接方式：Java JDBC + dbcp现象描述：
程序偶尔出现上述异常提示，我的程序内建有连接池重置处理，当出现上述异常后，自动重置连接池，一般能够重新连接上数据库。排除问题：
1、url连接串之类的问题
2、网络问题
3、其他简单配置问题（生产环境已经运行2年）怀疑问题：
1、是否服务器连接数不够？（自己做过实验，当应用达到DB最大连接数时的提示为拒绝连接，与此不同）
2、是否其他应用消耗DB服务器资源？（有怀疑，但没有证据，如哪位仁兄遇到类似问题，望不吝赐教）
3、操作系统连接数？（也是怀疑，是否HPUX的连接数不够了，公司的服务保障上去看了，说没有用完，不知哪位仁兄有类似经历）此问题已经困扰我很久，虽不致使系统瘫痪，但终究是块心病，望早日去之。
数据库服务器端环境：HPUX + Oracle9.2 （小机服务能力还是很强的，DB连接数约为300～400）
应用服务器端环境：Windows 2003 企业版 + Tomcat5.0.28
应用连接方式：Java JDBC + dbcp现象描述：
程序偶尔出现上述异常提示，我的程序内建有连接池重置处理，当出现上述异常后，自动重置连接池，一般能够重新连接上数据库。排除问题：
1、url连接串之类的问题
2、网络问题
3、其他简单配置问题（生产环境已经运行2年）怀疑问题：
1、是否服务器连接数不够？（自己做过实验，当应用达到DB最大连接数时的提示为拒绝连接，与此不同）
2、是否其他应用消耗DB服务器资源？（有怀疑，但没有证据，如哪位仁兄遇到类似问题，望不吝赐教）
3、操作系统连接数？（也是怀疑，是否HPUX的连接数不够了，公司的服务保障上去看了，说没有用完，不知哪位仁兄有类似经历）此问题已经困扰我很久，虽不致使系统瘫痪，但终究是块心病，望早日去之。
解决方案 »
- 回滚段的问题，谢谢！
- 关于存储过程在同一环境下执行效率时快时慢的解决方法，请高手指教！在线等
- .net 如何获得oracle中的timestamp格式数据?
- oracle里插入删除数据的问题？
- 请问把word,ppt，pdf存入blob字段中能否进行中文的全文检索
- 记录锁的问题
- 在Oracle中 用varchar2做主键或索引对系统性能有无不良影响？
- 第一次ORACLE发文：动态字段名实现问题
- ora9i (东邪) 所提的"ORACLE恢复的问题"???
- Oracle的sql developer里面脚本输出部分出现乱码
- 关于user_merge提示
- 请问出现SP2-0552: 未说明结合变量是什么原因
我这边专门写了一个模拟业务一直执行（保持了一定的业务压力），执行过程中出现前面所述提示，那么应该不存在时间问题。
另，像超时被DB主动断了的情况，只需要在连接池配置的时候增加一个取用前和归还后的验证查询sql即可，池会自动处理掉断了的连接。
我前面已经说了：（小机服务能力还是很强的，DB连接数约为300～400） ，肯定是改过Processes了，否则根本上不来。
而且，Processes不够的提示是拒绝连接，而不会出现：Io 异常: The Network Adapter could not establish the connection
Io 异常: The Network Adapter could not establish the connection 但是当时厂家给的回复就是这个..当时这边也是不影响正常的程序 但就是后台总报这个错误后来把数据库迁移到自己的服务器上 这个问题就解决了..---他们的主机我们没有很大的权限 所以具体他们那边就不清楚了
问一下，把数据库迁回到自己的服务器上，问题解决了，是否是吧应用和db放在了一起？
我实验过放在一起的情况，跟踪了一段时间，没有出现提示，一旦分开到不同的机器，当业务量上到一定程度的时候就会出现上述错误提示，真是头疼啊。PS. 我还做过环境实验，就是把Oracle挪到一台Windows2003的服务器上，执行业务慢了点，但没有出现异常提示。
可惜由于挪到Windows2003上后业务量并没有达到全业务的压力（客户嫌慢），没有说服力啊。
例如
136.224.24.71,
136.224.24.78,应用没有放在同一台机器上
而是在
136.224.24.70
136.224.24.79
做的集群~应用连接直接访问的双机地址类似于这样
nmdw =
(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = 136.224.24.11)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = 136.224.24.16)(PORT = 1521))(LOAD_BALANCE = yes)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = nmdw)))还有一点
我记得 原来总报错的时候 数据库是在单机状态下运行的~不知道您想知道是不是这些
工作要求：
1．计算机或相关专业本科以上学历，英语优良。
2．五年以上linux/unix/BSD管理经验。拥有大型网站尤其是大型JAVA-based网站的集群以及管理经验。熟悉linux/unix 的管理，配置，备份及灾难恢复。熟悉集群的架设，负载均衡的设置。
3．精通Mysql/Oracle，有相关数据库集群的架设经验，具有数据库优化经验。
4．精通Apache TOMCAT/Jboss 的各项管理配置。
5．精通C shell or Perl，精通各种Linux/unix 下软件的使用，如SSH SSL Iptables等。对网络安全有比较深刻的认识。能有效地防范网络攻击。北京睿朗阳光网络科技有限公司，是提供综合性彩票服务的龙头企业集团，拥有国际化的彩票系统技术解决方案，服务于东南亚、欧洲，及非洲多个国家。面向国内，旗下现有我中啦（www.wozhongla.com）、全国114彩票服务平台（http://www.114caipiao.com）、江西福利彩票服务平台（http://www.loto.jx.cn），以及上海福利彩票服务平台（http://www.loto.sh.cn）。2007年，公司实现销售额从零到4000万元人民币/月的骄人业绩，年收入达3亿多元人民币。
2008年，公司成功地完成了从互联网彩票服务平台向手机、固话、互联网彩票综合服务平台的转型。为公司进一步的发展奠定了坚实基础。
2009年，睿朗阳光正以全新的姿态蓄势待发，现提供优厚的薪金和福利待遇以及良好的发展空间，诚邀优秀技术开发人才的加盟!联系方式：
地址：北京市朝阳区东三环中路39号建外SOHO8号楼
邮编：100022
邮箱：[email protected]
UID2010081 帖子3 精华0 积分16 经验值130 点 阅读权限10 在线时间0 小时 注册时间2009-6-24 最后登录2009-6-24 查看详细资料
编辑 引用 评分 回复 TOP
(DESCRIPTION =(ADDRESS = (PROTOCOL = TCP)(HOST = 136.224.24.71)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = 136.224.24.78)(PORT = 1521))(LOAD_BALANCE = yes)(CONNECT_DATA =(SERVER = DEDICATED)(SERVICE_NAME = nmdw)))
刚才URL中那两个IP是映射地址真实地址应该是这个
工作要求：
1．计算机或相关专业本科以上学历，英语优良。
2．五年以上linux/unix/BSD管理经验。拥有大型网站尤其是大型JAVA-based网站的集群以及管理经验。熟悉linux/unix 的管理，配置，备份及灾难恢复。熟悉集群的架设，负载均衡的设置。
3．精通Mysql/Oracle，有相关数据库集群的架设经验，具有数据库优化经验。
4．精通Apache TOMCAT/Jboss 的各项管理配置。
5．精通C shell or Perl，精通各种Linux/unix 下软件的使用，如SSH SSL Iptables等。对网络安全有比较深刻的认识。能有效地防范网络攻击。北京睿朗阳光网络科技有限公司，是提供综合性彩票服务的龙头企业集团，拥有国际化的彩票系统技术解决方案，服务于东南亚、欧洲，及非洲多个国家。面向国内，旗下现有我中啦（www.wozhongla.com）、全国114彩票服务平台（http://www.114caipiao.com）、江西福利彩票服务平台（http://www.loto.jx.cn），以及上海福利彩票服务平台（http://www.loto.sh.cn）。2007年，公司实现销售额从零到4000万元人民币/月的骄人业绩，年收入达3亿多元人民币。
2008年，公司成功地完成了从互联网彩票服务平台向手机、固话、互联网彩票综合服务平台的转型。为公司进一步的发展奠定了坚实基础。
2009年，睿朗阳光正以全新的姿态蓄势待发，现提供优厚的薪金和福利待遇以及良好的发展空间，诚邀优秀技术开发人才的加盟!联系方式：
地址：北京市朝阳区东三环中路39号建外SOHO8号楼
邮编：100022
邮箱：[email protected]
UID2010081 帖子3 精华0 积分16 经验值130 点 阅读权限10 在线时间0 小时 注册时间2009-6-24 最后登录2009-6-24 查看详细资料
编辑 引用 评分 回复 TOP
谢谢，清楚你那里的情况了。
我这里也有一个客户现场与你那里的类似，使用了Oracle的集群，这种方式的连接确实没有出现过断连接的情况。
可这个现场不是集群，出现提示了，关键是找不到合理的解释，也就没法向客户提出建立集群的理由啊。
2.JDBC那边有没的例外处理有没有关闭连接?我遇到N次这种情况.
3.DB那边用的是共享模式?如果应用服务器那边用了连接池,DB最好用专用连接.
4.JDBC是不是每个页面,每个程序都会打开一个数据库连接?如果是换成静态的连接,一个应用用户只开一个连接就够了
5.IO,RAM看是否正常
6.看一下DB的警告日志看有没问题
7.查一下DB的等待事件
呵呵
希望你早日解决这个问题小弟能力有限~唉 要学的东西真多了~
交换网卡和交换机器实验都做过，不过效果不明显，因为现象本身就是偶尔出现，只不过有时较为频繁。
我同事倒也碰到过网卡有问题的情况，虽然邪门，但极其偶然，这里应该不是这样的情况。2.JDBC那边有没的例外处理有没有关闭连接?我遇到N次这种情况.
这种低级错误在这里应该不会发生，我们在闲时和实验环境进行过跟踪，确认连接关闭。
3.DB那边用的是共享模式?如果应用服务器那边用了连接池,DB最好用专用连接.
这种情况也考虑到了，我们使用的是专用连接模式。
4.JDBC是不是每个页面,每个程序都会打开一个数据库连接?如果是换成静态的连接,一个应用用户只开一个连接就够了
使用了池化管理，基于Servlet的访问线程级的连接处理，一次请求没有意外的话，整个业务处理过程仅仅使用一个连接。
5.IO,RAM看是否正常
从小机上的DB情况看，基本正常，没有特殊的异动。6.看一下DB的警告日志看有没问题
没有特殊的警告，换句话说，在客户端出现前述异常提示的时候，DB的所有日志中没有相关异常。
除了listener.log日志稍大，约1.6G，去之，重启DB后，异常提示依然会不定期出现。
7.查一下DB的等待事件
公司DB管理员远程查看服务器，没有出现异常的等待事件。总结，从常规角度看，似乎没有什么特殊的问题。
从上次检测，看到listener.log稍大，后来为此专门进行了跟踪，发现其建立连接的频率稍高，至少比业务执行所需要的频率大，那么就先从这里入手调优吧：减少数据库连接的建立次数。另外，结合前面说的，曾经做过实验当DB和应用在同一物理服务器时，没有出现过该异常提示，那么抽空继续做一下这个实验，争取时间长一点。
那俺继续说点可能性吧
1.换个高版本的JDBC驱动试试
2.防火墙有没一些对包的控制,最好关了防火墙试试
3.LISTENER.TNS里用的是DNS名还是IP？最好换成IP试试
造成ORA-12560: TNS: 协议适配器错误的问题的原因有三个：
1.监听服务没有起起来。windows平台个一如下操作：开始---程序---管理工具---服务，打开服务面板，启动oraclehome92TNSlistener服务。
2.database instance没有起起来。windows平台如下操作：开始---程序---管理工具---服务，打开服务面板，启动oracleserviceXXXX,XXXX就是你的database SID.
3.注册表问题。regedit，然后进入HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOME0将该环境变量ORACLE_SID设置为XXXX,XXXX就是你的database SID.或者右几我的电脑，属性--高级--环境变量---系统变量--新建，变量名=oracle_sid,变量值=XXXX,XXXX就是你的database SID.或者进入sqlplus前，在command line下输set oracle_sid=XXXX,XXXX就是你的database SID
上面各位的检查点都是有道理的，但不是这个问题的根本缘由，还是最后检查侦听日志发现了问题。
侦听日志比较大，经过检查，发现是由于程序连接相对比较频繁导致，深究其道理一说就明白了：
Windows下Oracle简单说是以线程为主进行请求响应的，因此连接频繁不会导致连接断提示；
Unix/Linux下Oracle简单说是以进程为主进行请求响应的，进程的启动毕竟需要的资源比线程要大，请求频繁后导致部分请求的进程来不及启动，这时就出现了上面的提示。解决方法很简单，进行连接的缓冲，对于一个Servlet线程内的连接进行缓冲，每段程序的连接获取首先从缓冲中获取自己线程的缓冲连接进行处理，而不是直接申请连接然后释放连接，最终Servlet线程生命终结时进行统一释放。这样的处理虽然把事务一定程度上拉长，但与原始要求基本一致，保持了Servlet请求生命周期内的事务完整。结束了，放分。