诡异的TNS-12541:TNS:nolistener

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了诡异的TNS-12541:TNS:nolistener相关的知识,希望对你有一定的参考价值。

更加怪异的是,重建监听也无效,还是报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端口,问题未现;重启数据库,监听自动注册。故障排除。

这个问题说明是由于日志太大无法写入导致数据库监听无法正常启动,建议手工定时清空数据库日志文件,以避免此类问题发生。

以上是关于诡异的TNS-12541:TNS:nolistener的主要内容,如果未能解决你的问题,请参考以下文章

诡异的尺寸

并发下诡异的HashMap

关于Asp.net mvc的诡异问题

lua "诡异"的return用法

史上最诡异的数学题

诡异的事件,记录一下