标签：说明 lis list listen 排除 细节 默认 one 修改
更加怪异的是，重建监听也无效，还是报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端口，问题未现；重启数据库，监听自动注册。故障排除。
这个问题说明是由于日志太大无法写入导致数据库监听无法正常启动，建议手工定时清空数据库日志文件，以避免此类问题发生。
标签：说明 lis list listen 排除 细节 默认 one 修改
原文地址：http://www.cnblogs.com/Minao/p/7250164.html
