在
oracle数据库中，如果不对监听日志文件（listener.log）进行截断,那么监听日志文件（listener.log）会变得越来越大，想必
不少人听说过关于“listener.log日志大小不能超过2gb，超过会导致listener监听器无法处理新的连接”，当然这个不是真理，不会绝对
出现，只是发生在老旧的32bit linux或unix系统下面，真实的原因是一些32bit
os自带的文件系统不支持2gb以上的文件，导致监听服务进程（tnslsnr）append write日志文件出错。
那么是否不需要对监听日志文件进行截断维护呢？ 答案是否定的。当然要对监听日志文件（listener.log）进行定期清理，如果不定期清理，会遇到下面一些麻烦：
1：监听日志文件（listener.log）变得越来越大，占用额外的存储空间。（当然现在存储白菜价，不差那几g的空间。但是我们还是要本着工匠情怀，精益求精）
2：监听日志文件（listener.log）变得太大会带来一些问题：listener.log日志大小不能超过2gb，超过会导致listener监听器无法处理新的连接。
3：监听日志文件（listener.log）变得太大，给写入、查看带来的一些性能问题、麻烦。
也有人说是监听服务进程一般使用标准c函数write写出到listener.log，listener.log文件时使用的是
o_wronly|o_creat|o_append，o_append即追加到文件的尾端，一般来说追加写方式不会因为文件越大写地越慢。撇开这个不
谈，在一个很大的监听日志文件（listener.log）查找某一天或某一个错误，这个确实会带来一些性能问题。查找起来也相当麻烦。
所以应该定期对监听日志文件（listener.log）进行清理，另外一种说法叫截断日志文件。关于截断监听日志，要注意一些问题。初学oracle的时候遇到一个错误的截断监听日志的，下面演示一下
如上所示，这样截断监听日志（listener.log）后，监听服务进程（tnslsnr）并不会将新的监听信息写入listener.log，而是继续写入listener.log.20150114
规范正确的流程应该这么处理：
step 1：首先停止监听服务进程（tnslsnr）记录日志。
step 2：将监听日志文件（listener.log）复制一份，以listener.log.yyyymmdd格式命名
[oracle@db-server log]$ cp listener.log listener.log.20150114
step 3：将监听日志文件（listener.log）清空。清空文件的方法有很多
3.1 echo “” > filename
3.2 cp /dev/null 或 echo /dev/null > filename
step 4：开启监听服务进程（tnslsnr）记录日志
[oracle@db-server log]$ lsnrctl set log_status on;
当然也可以移走监听日志文件（listener.log），数据库实例会自动创建一个listener.log文件。
当然这些操作应该通过shell脚本来处理，然后结合crontab作业定期清理、截断监听日志文件。例如网上的一个清理、截断监听日志文件的shell脚本。
这
样的脚本还没有解决一个问题，就是截断的监听日志文件保留多久的问题。比如我只想保留这些截断的监听日志一个月时间，我希望作业自动维护。不需要我去手工
操作。有这样一个脚本cls_oracle.sh可以完全做到这个，当然它还会归档、清理其它日志文件，例如告警文件（alert_sid.log）等
等。功能非常强大。
在crontab中设置一个作业，每天晚上凌晨零点运行这个脚本，日志文件保留31天。
00 00 * * * /home/oracle/_cron/cls_oracle/cls_oracle.sh -d 31 > /home/oracle/_cron/cls_oracle/cls_oracle.sh.log 2>&1
如下所示，非常自动化的维护、清理了监听日志文件（listener.log）,又能保留一段时间以便查找、跟踪问题
