OS：Microsoft Windows 2003 EnterPrise
Database:Oracle Database EnterPrise 11.2.0.1
内存：1G
2013年8月13日，是个特殊的日子，这天天空很蓝，城市的各个角落飘散着玫瑰花的香味，那是一个令人陶醉的日子，正享其中的时候，突然来了个电话，所有的一切的一切都泡汤了，全无了。
一客户现场工程师打电话过来，说数据库连不上了，监听起不来了，被告知报错TNS-12571:TNS:包写入程序失败，通过查询Metalink文档，让其修改$ORACLE_HOME/network/admin/SQLNET.ora文件，添加SQL.NET.AUTHENTICATION_SERVICES= (NONE)，后重启监听，结果无效。
约2个小时后，我来到用户现场；检查发现并没有报TNS-12571错误，而是报的TNS-12541:TNS:nolistener的错误，这个错误很明显就是监听没起来或是无法启动。随即手工起监听程序，结果发现起不来，报TNS-12541错误，应该可以判断是监听配置文件的问题，故检查后重建监听。
更加怪异的是，重建监听也无效，还是报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端口，问题未现；重启数据库，监听自动注册。故障排除。
这个问题说明是由于日志太大无法写入导致数据库监听无法正常启动，建议手工定时清空数据库日志文件，以避免此类问题发生。
