RMAN本身不默认写大量Trace文件，暴增源于隐式SQL跟踪被激活；需检查并关闭全局10046事件、清除RMAN脚本中debug参数、禁用DBMS_MONITOR对相关服务的跟踪，并确保DIAGNOSTIC_DEST与BACKGROUND_DUMP_DEST一致且指向专用路径，再用ADRCI按策略清理旧Trace。
rman 本身不默认写大量 trace，你看到的暴增 trace 文件，几乎全是“被连带触发”的 sql 跟踪，不是 rman 主动行为。
Trace 暴增的真正源头是隐式 SQL 跟踪被激活
RMAN 进程自身不开启 10046 跟踪，但它的底层调用（比如 DBMS_BACKUP_RESTORE 包、恢复目录查询、归档日志扫描）可能被已有跟踪策略捕获。常见触发点包括：
- 全局事件未关闭：
ALTER SYSTEM SET EVENTS '10046 trace name context off'没执行过，而之前有人开过10046且 scope=spfile，重启后仍生效 - RMAN 脚本里混入了
debug on（如run { debug on; backup database; }），该指令会强制打开会话级 10046 - 第三方备份工具或监控脚本在连接时设置了
sql_trace=true或event=10046，RMAN 子进程继承了这个会话属性 - 数据库启用了
SQL_TRACE的初始化参数（已废弃但残留配置），或通过DBMS_MONITOR对CLIENT_ID/SERVICE_NAME开了跟踪
Windows 环境下 NTFS 目录性能恶化会放大问题感知
Trace 文件暴增本身不一定立刻占满磁盘，但在 Windows Server + Oracle 11.2.0.1 组合中，单目录文件数超 5000 后，系统级目录遍历变慢，导致：
- 数据库启动时 PMON/SMON 扫描
$DIAG_DEST/rdbms/<dbname>/<instance>/trace/</instance></dbname>耗时剧增 -
lsnrctl status卡住几秒到几分钟，误判为“RMAN 挂起” - ADRCI 命令响应迟钝，让人误以为清理无效
- 管理员倾向手动
rm -rf *.trc，反而触发ORA-48192或破坏 ADR 结构
DIAG_DEST 配置错误会让问题更难定位
你以为改了 DIAGNOSTIC_DEST 就万事大吉？错。Oracle 11g+ 虽用 ADR，但老参数还在偷偷起作用：
-
BACKGROUND_DUMP_DEST若非空且路径与DIAGNOSTIC_DEST不同，部分 RMAN 相关进程（如ora_rman_*）会把 Trace 写到旧路径，造成“改了没用”的假象 -
DIAGNOSTIC_DEST若设在$ORACLE_HOME/log或根分区，RMAN 备份期间密集写 Trace 可能直接撑爆系统盘 - 必须运行
SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME IN ('diagnostic_dest', 'background_dump_dest');确认两者一致且指向专用大容量路径（如/u01/app/oracle/diag） - 若
BACKGROUND_DUMP_DEST有值，得用ALTER SYSTEM RESET background_dump_dest SCOPE=SPFILE;并重启实例
别删文件，用 ADRCI 按生命周期清理
手动删 .trc 是最危险的操作 —— 正在写的 Trace 被删会导致 Oracle 报 ORA-48192，后续所有 ADR 工具可能失效。正确做法是：
- 进
adrci，先set base /u01/app/oracle/diag，再show homes找到对应 RDBMS home（如diag_rdbms_orcl_orcl） - 按分钟单位清理：7 天前的 Trace 是
purge -age 1008 -type TRACE -home diag_rdbms_orcl_orcl - 写成脚本自动执行：
adrci -script purge.rsp，purge.rsp内容仅两行：set base /u01/app/oracle/diag和上面那条purge命令 - 清理频率建议设为每日一次，避免单次操作扫描上万文件拖慢 ADRCI
Trace 暴增从来不是孤立现象，它要么暴露了未关闭的调试开关，要么揭示了 DIAG_DEST 路径管理混乱，要么是 Windows 下 NTFS 性能瓶颈的显性信号 —— 光清文件不查根源，下周同一时间还会再爆。
