目錄
監聽狀态正常，應用回報時斷時連
listener程序crash
ora-12514 tns 監聽程式目前無法識别連接配接描述符中請求服務
11g scan listener無法注冊服務故障
listener hang
tns-12535 tns-00505處理
應用測試連接配接不上資料庫，連接配接直接報tns-12547: tns:lost contact處理
由oracle的listener引起的報錯很多，很大一部分是由于配置不當導緻的。通常，我們要麼從tnsnames.ora找原因，要麼從lisntener.ora找原因。基本上，我們從oracle連接配接的時候報出的錯誤代碼可以快速查到原因。
下面介紹的幾類故障及處理方法，難度稍微要大一些
故障現象:
用戶端新發起的短連接配接時斷時連，如下所示:
故障原因:
因短連接配接持續性發起連接配接耗盡監聽ip 1521端口資源，導緻監聽無法正常處理連接配接請求。
超過每秒50次連接配接則需要關注，可通過tail -20f listener.log 觀察，如持續性快速刷屏則可能已經出現連接配接風暴.
故障解決/日志分析:
故障環境：
作業系統為：sunos 5.10
資料庫版本：oracle 10.2.0.4
故障現象：
listener程序已經crash， 檢視主機資料庫監聽日志listener_ngsetdb3/4.log如下：
系統日志：
故障分析：
listener程序crash是由于ipmp出現故障所緻，listener随後在探測不到服務節點時，直接crash。oracle mos文章solaris cluster 3.x: ipmp group failure impact [id 1006916.1]對此有較長的描述：在sun cluster中，短暫的網絡故障會導緻ipmp組失敗，并觸發資源組切換。并且，它會在38秒後回切！
處理方法：
檢視監聽日志listener.log跟系統日志（/var/adm/ messages）。
手動重新開機兩個節點的listener，oracle提供了一個解決方案：修改/etc/default/mpathd檔案下的ipmp failure_detection_time變量值，即将失敗檢測時間從預設的10秒（10000）增加到20秒（20000）以上
注：修改該參數需要重新開機mpathd服務。
用戶端無法通過監聽連接配接資料庫
故障原因：
1.執行個體未注冊到listener中,可通過lsnrctl status 檢視
2.oracle process達到上限無法建立新的連接配接。
故障解決：
手工注冊資料庫,alter system register;
檢查資料庫使用者連接配接分布情況,并show process 檢視連接配接限制
select username,count(1) from v$session group by username order by 2 asc;
ps :大部分情況由開發商程式bug引起。
scan listener 無法注冊service服務
bug 13066936
故障解決:
任意環境
從其他應用主機tnsping發現延遲很大
檢視監聽狀态報如下錯：
listener.log有如下報錯：
故障分析:
too many open files意味着maximum number of open files per process 達到了上限。是以listener hang住的原因是該limit設定過小。
将oracle使用者的soft limit提升為至少1024，然後重新oracle使用者登入，檢驗ulimit合格後，重新啟動資料庫和監聽。
具體解決辦法如下：
在/etc/system增加以下行
set rlim_fd_max=65536
set rlim_fd_cur=4096
重新登入oracle并檢驗oracle使用者的限制
su – oracle
ulimit -ha
ulimit –sa
重新啟動資料庫和監聽
db alert日志報如下錯誤：
一個用戶端連接配接整個步驟：
用戶端發起一個connection連接配接監聽
監聽啟動一個專屬程序(伺服器程序，也就是我們通常說的loca=no程序)用于接收這個connection
在專屬程序啟動之後，監聽會将這個connection傳遞給這個專屬程序
專屬程序通過這個connection來跟用戶端握手
專屬程序跟用戶端資訊交換需要建立一個session
session打開
當在以上的第3步到第4步時用戶端關閉，是以當專屬程序嘗試跟用戶端聯系時發現連接配接已關閉時，就會報出我們看到的錯誤！！
錯誤一般是由于程式異常斷開導緻逾時，11g r1如果出現如上的錯誤資訊會寫入到sqlnet.log,11g r2會寫入到alert.log，
其實出現此錯誤是正常的現象。
如果不想這樣的資訊列印在alert日志中，
在sqlnet.ora設定
diag_adr_enabled = off
在listener.ora設定
diag_adr_enabled_ = off
重新開機監聽
環境：hp-ux 11.31 ia64
資料庫版本：11.2.0.4
應用測試連接配接不上資料庫，連接配接直接報tns-12547: tns:lost contact。
但檢視監聽狀态，crs狀态，資料庫狀态均正常。crs日志、css日志及agent日志均無報錯。
應用連接配接資料庫直接報tns-12547: tns:lost contact
監聽日志發現一直在報連接配接失敗:
問題導緻的原因有在32位平台中當listener.log超過2g會報這個錯。
oracle_home下的一些執行檔案權限不對也會導緻相同的錯誤，但我們這個是64位的，排除第一種，
是以去查詢執行檔案的權限是否正常。
1、 通過對比發現部分執行檔案少了s權限，做了relink all,重新同步執行檔案
2、 由于資料庫使用的是asm，磁盤屬組為asmadmin，故對比問題節點及正常節點db oracle_home下屬組為asmadmin的檔案，将問題節點檔案權限修正即可解決問題。
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2015-12-23</b>