昨天中午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的，這樣的設計方法，直接從數據庫層面發生了耦合，完全是不合理的。雖然暫時能收費了，我們還得儘快修改業務流程，避免數據庫層面耦合的發生。當然了，說服客戶對操作系統安裝補丁也是不可缺少的工作。
現在想來，第一次出現端口號被佔滿的時候，告知客戶服務器中毒是錯誤的，那次能解決問題不是因爲殺了毒，而是因爲服務器重啓了。
