引言：
在公司一台windows搭建的oracle的數據庫運行一直正常，突然昨天發生了發現在其他機器客戶端連接服務器的oracle數據庫連接不上，報錯17001，於是開始了本次故障處理。
oracle故障處理記錄過程
1：排查orale服務於客戶端機器是否網絡被做了限制，在客戶端通過telnet oracle主機的ip 端口，此項排查完畢，正常！
2：登錄oracle服務器，在windows機器的服務里查看oracle的數據庫服務和listenner是否是啟動狀態。 此項排查完畢，正常！
3：在oracle服務器，使用客戶端軟件工具連接oracle數據庫，連接不上，報錯異常為IO異常。因此懷疑為網絡限制或域名解析問題。
4：由於懷疑是網絡問題，所以先查看oracle配置文件的listenner中的host是否被人篡改或不能識別，排查完畢，正常！查看windows主機的host，位置：C:\Windows\System32\drivers\etc\hosts 發現這個hosts文件中沒有配置主機名與ip地址的對應，關系，於是加上后重啟listenner，仍然不能正常連接，排查完畢！
5：查看oracle數據庫服務器中的trace中的listenner日志，位置 ： $oracle_home\diag\tnslsnr\主機名\listener\trace\，發現日志里報錯的都是ORA-12570，百度搜索問題中有人回答是需要重啟監聽，這個我測試過，並沒有解決問題，也有的人回復需要將listen.ora中的HOST從主機名換成ip地址，這個也做過測試仍然不行。
6：進行原始命令連接，從windows機器上進行cmd的sqlplus連接，發現如果是sqlplus 用戶名/密碼 連接正常，但是如果使用 sqlplus 用戶名/密碼@ip地址：端口/實例 這樣的方式進行連接的時候返回的結果是 no listenner，這樣認定為listenner無響應。
7：進行命令對oracle數據庫的listener啟動，但是主機查詢listenner狀態響應無應答，命令輸完回車后listenner一直在等待中，無成功結果返回，但是服務中的listenner是啟動狀態的，這個就確實很奇怪，所以決定刪除listenner進行重建。
8：在windows服務器進行oracle的listenner的刪除與重建，但是發現刪除過程響應也非常慢，重建過程也很慢，最終重建完成之后去連接，最開始建立完成可以連接上，但是馬上就又連接超時了。
9：針對於這種情況需要去查看oracle啟動listenner的時候有什么報錯，去racle_home\diag\tnslsnr\主機名\listener\trace\listenner.log，日志量有4G左右，服務器中沒有安裝UE無法快速打開，於是停止了監聽，將listenner.log進行了備份后刪除了日志，對監聽進行了重啟，發現在cmd中運行lsnrctl status響應速度已經恢復。問題解決！
10：總結：由於之前從未遇到過這樣的情況，比較奇特，所以記錄一下，原來listenner的日志的大小會影響oracle監聽的運行，如果以后有類似的問題，大家也可以從這方面去查詢一些。