晚上十點多,一個朋友聯絡我說他們的資料庫有問題,客戶連線不上資料庫,沒有任何報錯,就是卡住,也不提示任何資訊.

這是一臺windows 資料庫,單例項資料庫版本為11.2.0.1.遠端到伺服器之後檢視資料庫,發現數據庫執行正常,檢視監聽發現異常,使用lsnrctl status 直接卡住.嘗試使用lsnrctl start啟動,發現報錯監聽已經存在,檢視監聽服務確實已經啟動.

這種情況第一反應就是監聽日誌檔案達到了4G,導致無法寫日誌.根據經驗進入到$ORACLE_HOEM/diag/tnslsnr下面的目錄下檢視監聽日誌檔案,發現檔案只有1M.

難道是監聽的名稱錯了?檢視listener.ora檔案發現監聽的名稱也是對的.

還有一種可能,是伺服器的端口占滿了,但是那種情況是監聽都無法啟動,使用netstat -an檢視埠發現也是正常的,遠沒有達到65535個,這裡突然先入了僵局...

查找了一下mos,一篇文章也是說監聽的日誌檔案達到了4GB導致的,但是查了沒有啊?

這裡我又詳細檢查了一下listener.ora檔案,如下:

發現了一個關鍵的配置資訊:

ADR_BASE_LISTENER=

這裡配置的是ORACLE_HOME\log,正常的配置應該是ORACLE_BASE目錄才對

這個配置是配置ADR目錄的,也就是說監聽的日誌檔案將寫到此目錄下,而不是ORACLE_BASE\diag下

因此我靠經驗到$ORACLE_BASE\diag\tnslsnr下檢視的trace監聽日誌檔案是不對的.

進入到$ORACLE_HOME\log下的tnslsnr檢視trace檔案,發現listener.log確實達到了4GB,停止監聽,將此檔案刪除即可.

總結:

萬事不要憑經驗,其實oracle提供了命令讓我們檢視監聽日誌檔案:

lsnrctl

>show log_file

可以檢視監聽日誌xml檔案的位置.

對於一些沒有人維護的資料庫,特別是windows系統,建議直接將oracle 監聽日誌關閉

>set log_status off

>save_config

這次故障從我接手到恢復花費了20分鐘,業務也就至少停了20分鐘,這個系統是一個7x24小時的核心繫統,停20分鐘影響還是非常大的,其實最開始通過故障現象我就定位到了可能是檔案過大導致的,如果一開始直接通過命令檢視日誌檔案路徑,只要2分鐘就可以解決故障.