引言：
在公司一台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:WindowsSystem32driversetchosts 发现这个hosts文件中没有配置主机名与ip地址的对应，关系，于是加上后重启listenner，仍然不能正常连接，排查完毕！
5：查看oracle数据库服务器中的trace中的listenner日志，位置 ： $oracle_homediag nslsnr主机名listener race，发现日志里报错的都是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_homediag nslsnr主机名listener racelistenner.log，日志量有4G左右，服务器中没有安装UE无法快速打开，于是停止了监听，将listenner.log进行了备份后删除了日志，对监听进行了重启，发现在cmd中运行lsnrctl status响应速度已经恢复。问题解决！
10：总结：由于之前从未遇到过这样的情况，比较奇特，所以记录一下，原来listenner的日志的大小会影响oracle监听的运行，如果以后有类似的问题，大家也可以从这方面去查询一些。