目录
一、Oracle监听日志
1.1.日志产生原因
1.2.为什么需要清理？
二、清理核心原则
三、手动清理整体流程（实验环境-11.2.0.4.0）
3.1.查看集群状态
3.2.查看监听状态
3.3.确认监听状态正常之后（暂停监听记录）
3.4.清理备份日志文件（含备份）
3.5.打开记录日志（恢复日志写入）
四、自动轮转方案（推荐长期使用）
五、关键注意事项
一、Oracle监听日志
1.1.日志产生原因
日常生产中，数据库连接会话一般都是通过监听登陆数据库，pmon进程会将动态注册的信息写到监听日志文件中去，这时就会向监听日志文件写日志。
1.2.为什么需要清理？
当数据库运行长时间之后，日志文件就会一直变大，这时就需要定时清理！如果不清理，当日志大小达到 4G 左右的时候，不会向监听日志文件写新的内容，这时可能会导致数据库宕机，无法使用！故需要定期进行清理。
二、清理核心原则
清理 Oracle 监听日志的核心原则是：不能在监听器运行时直接删除或重命名文件，否则可能导致日志写入异常或空间无法释放。推荐通过“停止写入→备份/清空→恢复写入”的流程操作，或配置自动轮转。
三、手动清理整体流程（实验环境-11.2.0.4.0）
3.1.查看集群状态
3.2.查看监听状态
一般执行lsnrctl status会直接显示监听器的状态和日志配置路径，如下图：
注意：监听日志的清理不是直接给监听器直接做删除操作
3.3.确认监听状态正常之后（暂停监听记录）
进入监听器命令控制台，执行以下命令暂停监听配置（关闭记日志）：
show status
set log_status off;
注意：此操作仅暂停日志记录，不影响数据库正常连接和运行 。
3.4.清理备份日志文件（含备份）
可以根据上边的log日志路径找到目标文件，也可以执行：find $ORACLE_HOME -name listener找目标文件。
示例：
# 1. 移走并备份（此时建议立刻重启监听器）
mv listener.log listener_20231026.log.bak# 2压缩旧日志（只保留源文件，tar会自动加.gz后缀）
tar -czvf listener_20231026.log.tar.gz listener_20231026.log.bak
也可以
cp listener.log listener.log.bak
> listener.log
注意：使用 > 重定向清空，而不是 rm 删除。监听器运行时持有文件句柄，直接删除后磁盘空间不会立即释放。
3.5.打开记录日志（恢复日志写入）
-- 打开记录日志：监听器会自动继续向清空后的文件写入日志 。
LSNRCTL> set log_status on
-- 重新加载监听
LSNRCTL> reload
四、自动轮转方案（推荐长期使用）
使用 logrorate 实现按大小或按天自动切割、压缩和清理。在 /etc/logrotate.d/ 下创建配置文件：
/u01/app/oracle/diag/tnslsnr/<主机名>/listener/trace/listener.log { daily size 100M rotate 7 compress missingok notifempty copytruncate }关键选项 copytruncate：先复制日志内容再清空原文件，避免监听器因文件被移走而丢失写入句柄 。测试配置后强制执行一次验证效果：
logrotate -d /etc/logrotate.d/oracle-listener logrotate -f /etc/logrotate.d/oracle-listener五、关键注意事项
不要直接
rm监听日志：监听器运行时持有文件句柄，直接删除后磁盘空间不会释放，且日志写入可能异常 。清理前先备份：保留一份归档日志，便于后续排查历史连接问题。
在业务低峰期操作：虽然 set log_status off 不影响连接，但操作期间仍建议避开高峰 。
检查日志异常增长根源：如果日志短期内急剧膨胀，应排查是否有大量连接失败或异常请求，日志本身不是问题根源。
