文章轉自：http://www.luocs.com/archives/464.html
此文版權歸作者 – yaogang所有，轉載請注明yaogang©www.luocs.com。
Luocs說：這是我一個朋友的一個監聽器問題解決案例，這是昨天發生的事情，我一直跟朋友一起Troubleshooting，折騰了半天最后是BUG所致。再次汗顏，Windows平台惹不起啊！好，那么下面開始分享我朋友的案例！
環境描述：
OS : Windows Server 2008 64Bit (做了HA)
DB : 11.1.0.7.0
排錯過程：
前天應用不能訪問數據庫了 (后台應用能訪問數據庫)，故障發生。
馬上登錄到服務器里查看監聽狀態,發現有TNS-12541 ，TNS-12560等錯誤
Luocs補充：我跟朋友要了錯誤代碼，但他沒有保存，就直接貼圖。
從計算器的管理 –> 服務選項 –> 檢查oracle 監聽服務程序，發現該服務已經停止。
手動把監聽服務啟動，這時候服務狀態上顯示為已啟動，但在CMD窗口執行lsnrctl status的時候依然返回錯誤信息：
C:\>lsnrctl status LSNRCTL for 64-bit Windows: Version 11.1.0.7.0 - Production on 12-11月-2012 18:1 8:32 Copyright (c) 1991, 2008, Oracle. All rights reserved. 正在連接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.203.218)(PORT=1521))) TNS-12541: TNS: 無監聽程序 TNS-12560: TNS: 協議適配器錯誤 TNS-00511: 無監聽程序 64-bit Windows Error: 61: Unknown error 正在連接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC1521)))
過段時間回顯非常慢。
然后我檢查了下告警日志，大量的ora錯誤
Fatal NI connect error 12170. VERSION INFORMATION: TNS for 64-bit Windows: Version 11.1.0.7.0 - Production Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.1.0.7.0 - Production Time: 12-11月-2012 15:23:33 Tracing not turned on. Tns error struct: ns main err code: 12535 TNS-12535: TNS: 操作超時 ns secondary err code: 12560 nt main err code: 0 nt secondary err code: 0 nt OS err code: 0 Client address: <unknown> ORA-609 : opiodr aborting process unknown ospid (4116_6104)
這時候朋友懷疑是不是監聽器配置問題，就把原先的監聽器刪除重建了下，問題依然。
網上有個解決TNS-12535錯誤的案例，平台和版本都很類似，如下：
1、在 sqlnet.ora文件中 增加如下行:
DIAG_ADR_ENABLED = OFF
2、在listener.ora文件中增加如下行:
DIAG_ADR_ENABLED_<listenername> = OFF
如何監聽是listener時,則前面的名稱為:DIAG_ADR_ENABLED_LISTENER = OFF
3、重新啟動windows服務管理中的監聽程序.先停止,然后再重新啟動.
4、檢查結果.發現可以了,返回的值在10毫秒.有時為0毫秒.成功!!
但這並不是問題發生原因，在繼續排查過程中偶然發現監聽日志大小居然為4G。然后把這現象告訴了Luocs。
過了一會兒，Luocs回應是Oracle一個BUG，BUG號為9879101 : THE CONNECT THROUGH LISTENER WAS SLOW WHEN LISTNER LOG GROWED 4GB。
Luocs還提供了MOS上一篇文章，ID 1319797.1 : WINDOWS: Listener Hangs & Lsnrctl Commands Are Slow or Hang，里面給出了解決方法：
You can solve this problem by deleting the large listener in $ORACLE_BASE\diag\tnslsnr\<hostname>\listener\trace\<listener_name>.log 1) Stop the listener process using the command line or Control Panel Service. 2) Delete the log file(s) that are at or approaching the 4G size limit at this location: $ORACLE_BASE\diag\tnslsnr\<hostname>\listener\trace\<listener_name>.log 3) Issue any lsnrctl command and you will see a new listener.log in its place under: $ORACLE_BASE\diag\tnslsnr\<hostname>\listener\trace\ Since ADR Diagnostics are enabled for this listener these steps cannot be done dynamically using the lsnrctl utility. e.g. LSNRCTL>set log_file mylog Will yield: TNS-01251: Cannot set trace/log directory under ADR. However, it is possible to disable the flat file listener logging using the following commands: LSNRCTL>set current_listener <listener_name> LSNRCTL>set log_status OFF LSNRCTL>save_config
我就按照以上說明如下進行：
1）LSNRCTL進入交互模式
2）執行set current_listener LISTENER
3）set log_status off
4）stop 停止監聽器
5）手工刪除ADR指定的監聽日志路徑下的listener.log文件
6）start重啟監聽器
7）status查看狀態
到此問題解決。
雖然最后解決過程僅僅耗費了短短幾分鍾時間，但整個排錯過程卻是令人驚訝。在此整理，並與遇到同樣問題的朋友分享。