上周五下午，监听某银行核心系统突然报出连接超时，日志排查了半小时才发现，清理监听日志文件已经膨胀到27GB，监听把磁盘撑满了。日志这类事故在运维圈子里太常见了——Oracle监听日志不像数据库告警日志那样有人盯着，清理它就像个闷声不响的监听垃圾桶，日积月累，日志直到某天把整个系统堵死。清理

清理这玩意儿，监听最笨的日志办法是直接删文件。很多人以为停掉监听，清理删了log.xml，监听再启动就完事。日志可这么干有个隐患——如果数据库还在运行，清理监听进程会一直持有文件句柄，删了文件但空间不释放，磁盘照样满。而且直接删掉整个日志，后续排查问题连个痕迹都没有。

更稳的做法是truncate，不是delete。用lsnrctl set log_status off暂停写入，然后cat /dev/null > listener.log清空内容，最后再开启日志。整个过程监听服务不用重启，对业务零影响。我见过一个老DBA用这招处理过生产库，当时在线用户两千多，操作完连个告警都没触发。

但每次手动清都太被动。真正靠谱的方案是写个shell脚本挂crontab，每天凌晨三点检查文件大小，超过500MB就自动清。脚本里得注意两点：一是清空后要确认监听日志状态确实重新开启了，二是保留最近几天的日志做归档，别一股脑全扔了。有个同事图省事，脚本里直接rm -f，结果第二天要查前天下午的会话记录，傻眼了。

还有个细节容易被忽略——Oracle 12c以后监听日志默认路径变了，在$ORACLE_BASE/diag/tnslsnr/主机名/listener/trace/下，文件名也改成了listener.log.xml。很多老脚本还盯着11g的路径，自然找不到文件。上周帮一家企业排查，他们的清理脚本跑了半年，实际上一直在删一个不存在的文件，真正的日志早把/home分区撑爆了。

磁盘空间告急时，可以临时把日志级别调低，比如从listener改成off，但别长期这么干——真出了连接问题，没有日志等于瞎子摸象。折中方案是开启log rotation，Oracle 11.2.0.4以后支持LISTENER_LOG_ROTATION_SIZE参数，设个20MB自动轮转，老日志自动备份成listener.log.1、listener.log.2这种格式，配合系统logrotate定时压缩，能省不少事。

最后说个实战教训。那次帮银行处理完磁盘告警，顺手检查了他们的清理脚本，发现定时任务跑了两年，但脚本里写的是find /u01/app/oracle -name "listener.log*" -mtime +7 -exec rm -f——这命令会把所有7天前的日志删掉，包括正在写入的那个。结果每天凌晨三点，监听就默默失去日志记录能力，白天出了问题根本查不到原因。他们居然带着这个bug跑了两年，直到那天磁盘满了才发现。

清理日志这事看着简单，但坑全在细节里。路径对不对、文件句柄释放没释放、日志轮转开没开、脚本有没有误删正在写的文件——每一条都踩过雷。下次再遇到监听日志爆满，先看看这些地方，别急着删文件。