ORA-12570错误处理的简单记录-oracle数据库故障处理记录引⾔：
在公司⼀台windows搭建的oracle的数据库运⾏⼀直正常，突然昨天发⽣了发现在其他机器客户端连接服务器的oracle数据库连接不上，报错17001，于是开始了本次故障处理。
oracle建立数据库连接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，百度搜索问题中有⼈回答是需要重启监听，这个我测试过，并没有解决问题，也有的⼈回复需要将a中的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监听的运⾏，如果以后有类似的问题，⼤家也可以从这⽅⾯去查询⼀些。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。