昨天中午10点，突然接到总经理电话，说有客户反应LIS和PACS无法收费了，必须马上给处理掉。但是客户端PC却能连接到oracle服务器，没有使用dblink的业务运行都正常。LIS和PACS计费由于要连接不同的数据库，使用了dblink。经过初步排查发现dblink无法连接了，重新创建dblink也不好用。突然想到，会不会是服务器的所有端口号被占满了呢？因为以前有家客户的服务器就是由于所有端口号被占用，造成了数据库无法备份。当时查到所有端口号被占用后，我咨询了一位比较熟悉ORACLE的同事。他告诉我可能是服务器中病毒了。虽然当时客户对服务器中毒的解释深表怀疑，但是还是联系硬件厂商对服务器进行了查杀病毒并重启了服务器，服务器重启之后问题解决了。我让现场工程师查了一下，果然服务器所有端口号被占用了。

        难道又是病毒在作怪?这次我自己都开始怀疑了，这种情况不同的客户都出现过，应该不太可能是病毒的原因。由于两家客户用的都是windows操作系统。我开始怀疑是不是操作系统的问题。有了这样的想法之后，终于在微软官网上面找到了答案，的确是操作系统bug。官网是这样描述的：All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2。Windows Vista，Windows 7，Windows Server 2008，Windows Server 2008 R2，这些操作系统在启动第 497 天后，将不关闭 TIME_WAIT 状态的所有 TCP/IP 端口。这样的话，所有端口号很快就会被占满的。由于dblink需要临时端口号，当没有端口号可用的时候，dblink就无法使用了。

        由于客户比较着急，我建议他们立即重启服务器。但是时间是中午10点，虽然是周末，但是业务量还是比较大的，客户不同意重启服务器。通过查看使用dblink的源码，发现dblink跨数据库操作只是为了避免并发。在确认暂时注释掉dblink对业务影响不是很大的情况下，我让现场工程师把dblink相关的操作给注释掉了。业务马上恢复了正常。

        其实我一直反对在业务中使用dblink的，这样的设计方法，直接从数据库层面发生了耦合，完全是不合理的。虽然暂时能收费了，我们还得尽快修改业务流程，避免数据库层面耦合的发生。当然了，说服客户对操作系统安装补丁也是不可缺少的工作。

        现在想来，第一次出现端口号被占满的时候，告知客户服务器中毒是错误的，那次能解决问题不是因为杀了毒，而是因为服务器重启了。