你遇到过Windows环境Oracle11g版本trc文件过多导致启动慢、监听卡顿的问题么

在WindowsServer上运行Oracle 11.2.0.1时，大量.trc跟踪文件堆积（超过1万甚至更多），会直接引发：数据库启动极慢、lsnrctl status卡住、监听重启慢、数据库连接慢、服务器I/O高等典型问题。最近有遇到过一次，本文就从原因、危害、一键清理、永久根治全流程给出可直接落地的运维方案，适用于所有Windows+Oracle 11g环境。

一、问题现象

如果你也用过windows server下部署的Oracle 11g（11.2.0.1版本）数据库时，你一定遇到过如下情况：

• 数据库启动耗时从几分钟变成十几分钟甚至更久
• 执行lsnrctl status长时间无响应、卡住、超时
• 数据库重启、关闭都明显变慢
• 监听启动、停止、 eload极慢
• 磁盘trace目录下文件数成千上万，越积越多
• 系统磁盘IO高、服务器整体响应变卡

这些问题不是偶然，而是Windows+Oracle 11.2.0.1的机制性通病。

二、原因及危害

在windowsserver平台下，出现此情况还是非常常见的，主要有如下原因：

1. 文件系统目录遍历性能瓶颈(Windows NTFS特性)

这是最直接的原因。

• 单目录文件数限制效应：虽然NTFS文件系统理论上支持数百万个文件，但在实际应用中，当单个目录下的文件数量超过一定阈值（通常认为在5000-10,000个以上）时，文件系统的读写效率会显著下降。
• 启动与监听时的扫描行为：

1) 数据库启动：Oracle实例启动时，后台进程（如PMON,SMON,DBWn等）可能会尝试读取或清理诊断目录中的某些状态文件，或者在初始化ADR（自动诊断存储库）时扫描目录结构

2) 监听器(lsnrctl status)：监听器在启动或执行status命令时，需要访问其日志和跟踪目录（通常在$ORACLE_BASE/diag/tnslsnr/.../trace）。如果该目录下有上万个.trc和.log文件，操作系统在进行文件句柄分配、目录枚举或元数据读取时会消耗大量CPU和I/O时间，导致命令响应极慢甚至超时

3) 重启过程：重启包含关闭和启动两个阶段，关闭时需要写入最终的跟踪信息，启动时又面临上述的扫描问题，双重加剧了延迟。

2. Oracle 11g ADR(Automatic Diagnostic Repository)机制

Oracle11g引入了ADR来统一管理诊断文件，默认路径由DIAGNOSTIC_DEST参数决定。

• 缺乏自动清理策略：虽然ADR提供了ADRCI工具来管理文件生命周期（通过PURGE命令），但如果未配置定时任务或保留策略（Retention Policy），旧的trace文件不会自动删除
• 11.2.0.1版本的Bug或缺陷：11.2.0.1是11g R2的初始版本，存在较多已知Bug。在某些特定错误频繁发生（如连接报错、内部错误ORA-600/7445、RMAN备份异常）时，可能会触发死循环式的Trace文件生成，且该版本在处理大量ADR文件时的性能优化不如后续补丁集（如11.2.0.4）
• 诊断进程阻塞：当后台进程试图写入新的trace文件时，如果文件系统因文件过多而响应缓慢，可能会导致写操作阻塞，进而拖慢整个实例的启动流程

3. 潜在的根源性问题(为什么会有这么多文件？)

文件多通常是“果”而非“因”。需要排查是什么导致了Trace文件的疯狂增长：

• 应用程序连接错误：应用层频繁发起错误的连接请求（如密码错误、服务名错误），每次失败都可能生成一个trace文件
• SQL跟踪未关闭：某些会话可能开启了SQL Trace(Event 10046)但未正常关闭
• RMAN备份问题：RMAN备份失败或警告有时会生成大量trace
• 硬件或系统不稳定：磁盘I/O错误或内存问题导致Oracle进程异常终止并生成Dump
• 数据库bug导致进程频繁崩溃

只要异常不解决，trc文件会几分钟生成上百个。

4. 危害

如果不处理会越来越严重，主要有如下危害：

• 数据库启动越来越慢，最终无法启动
• 监听不可用，业务全部断连
• 磁盘占满，数据库直接宕机
• 系统IO被占满，影响其他应用
• 问题反复出现，运维成本极高

三、紧急处理方案

以下命令全部在Windows CMD(管理员权限下)运行，可以按照步骤参考处理：

第一步：停止监听与数据库（避免文件占用）

lsnrctl stop
sqlplus / as sysdba
shutdown immediate
exit

若无法关闭，直接在服务里停掉：

第二步：定位trace路径

执行下面SQL查看路径（启动到mount状态也可）：

select value from v$diag_info where name='Diag Trace';

典型路径：

监听日志路径：

$ORACLE_HOME\network\log

第三步：清理.trc，.trm旧文件

在CMD中cd进入trace目录，执行：

del /s /q *.trc
del /s /q *.trm

或者手动清理也可

第四步：清理并重建监听日志（解决4GB BUG）

进入network/log目录：

del listener.log
echo.>listener.log

也可以手动清理，但是建议先重命名，便于后续排查。

第五步：启动数据库与监听

sqlplus / as sysdba
startup
exit
lsnrctl start

执行后你会立刻发现数据库启动秒启、lsnrctl status瞬间返回、服务器不再卡顿。

四、根治方法：让trc不再堆积

1. 设置ADR自动清理（Oracle级根治）

用sysdba执行：

-- 保留3天的trace文件
alter system set diagnostic_diag_purge_min_age = 4320 scope=spfile;
-- 清理7天前所有trace
exec DBMS_SHRINK_CATALOG.PURGE_ALL_DIAGNOSTIC_DATA(SYSDATE-7);

2. 监听自动轮转（彻底解决4GB BUG）

编辑listener.ora，增加：

LOGGING_LISTENER = ON
LOG_FILE_LISTENER = listener
LOG_DIRECTORY_LISTENER = $ORACLE_HOME\network\log
LOG_ROTATION_LISTENER = ON
LOG_ROTATION_SIZE_LISTENER = 100M
LOG_ROTATION_AGE_LISTENER = 1D

3. 关闭多余跟踪（防止疯狂生成trc）

alter system set sql_trace = false scope=spfile;
alter system set events '10046 trace name context off';

4. Windows计划任务（定期清理兜底）

新建bat每日执行：

del /s /q "C:\app\Administrator\diag\rdbms\orcl\orcl\trace\*.trc"
del /s /q "C:\app\Administrator\diag\rdbms\orcl\orcl\trace\*.trm"

5. 根因排查

清理只是治标，必须查异常，排查为什么你的trc会暴增？

• 查看最近错误

select to_char(first_time,'yyyy-mm-dd hh24:mi'), message
from v$alert_log
order by first_time desc;

• 查看最新trc内容

select * from v$diag_trace_file order by last_update_time desc;

• 常见必须修复的问题

ORA-600、ORA-7445：数据库bug，打PSU补丁
监听TNS-12500系列错误：网络/权限/配置
进程频繁重启：内存、PGA、SGA配置不当
死锁、行锁、事务异常：应用SQL问题

五、总结

Windows上Oracle11.2.0.1版本的trc文件过多导致启动慢、监听卡，本质是Windows NTFS不适合海量小文件、Oracle11.2.0.1无自动清理监听日志4GB的BUG三个问题的叠加；可以通过先清理、再配置自动清理、最后查错误的步骤，从根源杜绝文件暴增。