共计 854 个字符，预计需要花费 3 分钟才能阅读完成。
更加怪异的是，重建监听也无效，还是报 TNS-12541 错误，而且启动过程非常慢，随即我查看了硬件配置，和数据库的参数配置，虽然比较低，但也不至于数据库能起来，监听起不来呀，随后检查端口，发现存在 1521 端口，说明监听是起来的，这个时候，我手工 shutdown 数据库，停止数据库所有服务。再次查看，发现还是存在 1521 的端口在线，开始猜测 本机除了数据库还有其它应用在占用着 1521 端口，随即修改监听默认端口，改为 152，再次重启监听，还是一样报 TNS-12541:TNS:nolistener；通过查看端口，152 端口不存在，确定监听是没有起来的。
这个时候 再猜测 ，估计是内存间通信导致；要正确判断这个问题，就是将相关服务都禁用掉，把服务器重启，再经用户的同意之后，重启服务器，检查当前服务器的存活端口，没有 1521 端口，这判断 1521 端口没有被其它自启动软件占用，故再次启动监听， 还是报同样错误：TNS-12541:TNS:no listener；这个时候就纳闷了，监听日志大小达到 4G，无法打开，当然就无法分析。
但是我注意到一个细节，就是我怎么操作监听服务，listener 日志大小都不变，这个时候我将 listener.log 日志文件剪切到桌面，重新在原目录下创建同名的 listener.log 文件，并赋予 Everyone 写入权限，再次启动监听，这个时候没有报错，启动速度非常快。而且这个新建立的 listener.log 文件也记录监听的启动信息，没有问题；随后将监听端口修改为默认的 1521 端口，问题未现；重启数据库，监听自动注册。故障排除。
这个问题说明是由于日志太大无法写入导致数据库监听无法正常启动，建议手工定时清空数据库日志文件，以避免此类问题发生。
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2017-10/147392.htm
