目录

一、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 不影响连接，但操作期间仍建议避开高峰 。

• 检查日志异常增长根源：如果日志短期内急剧膨胀，应排查是否有大量连接失败或异常请求，日志本身不是问题根源。