最近碰到一個蠻有啟發意義的案例。是資料庫監聽相關的，但是實際的原因卻又出乎意料。

問題的反饋受益於開發同學，一個開發同學在lync上找到我，說現在一個線上業務的資料庫訪問有些問題，想問問我是否有什麼建議。大體瞭解了下，他們在使用一個非1521的埠，比如埠是1525，他們在業務端看到的錯誤資訊類似下面的樣子：

java.sql.SQLException: Io exception: The Network Adapter could not establish the connection 這個問題讓我有奇怪，因為這個時間段我們也沒有做資料庫維護的工作，帶著疑問我登入到了這個環境，發現網路確實有一些卡頓，我還在安慰開發同事，是不是網路超時引起的，我再確認一下。

登入到了系統端之後，資料庫是可用的，連線數有近800多個，所以說業務應該沒有收到什麼大的影響，而這位開發同學反饋的1525埠訪問有問題是怎麼回事呢，我查看了監聽器的情況，發現1525的監聽埠竟然沒開，這就有些奇怪了。難道是誰把這個監聽器停了？

顯然不合理。所以我們需要檢視日誌來看看，這個埠是之前就沒有開啟還是有問題，因為資料庫版本較老，是一個10gR2的庫，就在$ORACLE_HOME/network/log下找到了日誌，找到1525埠對應的日誌，發現最近的日誌竟然是下面的內容:

Started with pid=11954 Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=10.127.xxx)(PORT=1523)))

然後就嘗試手工啟動，結果系統層面也遲遲沒有響應，稍等了一會，還失敗了，最後報出的錯誤還是空間不夠。

那麼這個問題到底該怎麼解釋，我認真梳理了下df -k的全部結果，發現/var目錄竟然滿了，多麼低階的一個錯誤，當然看到這裡，問題的解決思路也一下子清晰起來。

說千遍萬遍，竟然是因為空間的問題，這個很不應該啊。為什麼會有這種情況呢，系統層面應該是有一個排程任務去刪除額外的空間，但是頻率還是不高，就在這個間隙出了這個問題，我想看看到底是哪裡的日誌溢位了，很快就發現是/etc/adm下的日誌。

這個目錄下的日誌怎麼會有這麼多呢，我想起來前段時間啟用了syslog的選項，一些系統層面的操作都能夠記錄在案，沒想到沒過多少時間，竟然把這個目錄都撐滿了。

我對於這個問題的原因還是很感興趣，畢竟手工刪除，或者儘可能頻繁的清理日誌沒有抓住問題的本質，我查看了一圈日誌，發現監聽成功啟動之後，syslog裡面的日誌竟然生成非常頻繁。

幾乎是一秒一條記錄的速度，這個看起來明顯不正常啊。

日誌的內容類似下面的形式：

Apr xx 11:11:39 xxxx.com ipmon[17088]: [ID 702911 local0.warning] 11:11:38.740903 e1000g0 @0:1 b 10.127.xxxx -> 10.127.xxxx PR icmp len 20 84 icmp echo/0 IN 幾乎每秒一條的記錄，這對於系統其實壓力是潛在的，我就想這伺服器都老態龍鍾了，經不起這麼折騰，但是通過這個日誌該怎麼分析原因呢。

首先使用telnet xxx 1523這種方式的日誌明顯不是上面的輸出，那麼是不是連線到資料庫的頻率太高了呢，這個也不大可能，裡面有icmp的字樣，可以通過listener.log看到資料庫中的連線頻率遠沒有日誌中那麼頻繁。這個資訊該怎麼解釋呢，我就換了中思路，如果是我要嘗試測試連線，會用哪些方式，除了telnet，ssh,還有一種很常見的就是Ping了。

一想到這裡，再來看看日誌，還真有點意思，我找了臺伺服器，模擬了這個過程，發現日誌就是這個樣子的，所以我就初步定為了問題可能的原因，就是應用伺服器沒有關閉ping，導致了資料庫端的日誌量頻繁生成，最後導致磁碟空間爆滿。

和系統的同學聊了下他們有針對性的進行了排查，還真找到一個指令碼，確實在呼叫ping的操作。禁用之後，這個問題就基本解決了，而且想想我心裡還更踏實些。