rman内存占满卡死主因是元数据同步阶段的隐式排序与linux内核pagecache堆积，非压缩本身；需调优vm.min_free_kbytes、vfs_cache_pressure并确保configure compression algorithm 'basic'生效。
rman 在 oracle 12c 中对 as compressed backupset 的处理本身不直接消耗大量内存，真正吃内存的是元数据同步阶段的隐式排序操作——不是压缩过程，而是备份完成后清理、校验、报告时触发的跨视图关联查询。
DELETE INPUT 或 REPORT OBSOLETE 阶段卡住并爆 ORA-01652
这类命令会触发 RMAN 内部调用
DBMS_RCVMAN包，在V$RMAN_BACKUP_JOB_DETAILS和控制文件之间做 JOIN + ORDER BY + GROUP BY 查询查询未走索引，且默认启用全量扫描，大量中间结果 spill 到
CJCTEMP（或默认TEMP）表空间错误日志中若出现
RMAN-03002后紧跟ORA-01652，且时间点落在 “deleting archived logs” 或 “updating recovery catalog”，基本可锁定是元数据同步导致不是备份本身在压缩，而是后续维护动作在“算账”
多个并发 RMAN session 会各自分配 sort segment，叠加后迅速耗尽 TEMP 空间
SELECT * FROM v$tempseg_usage WHERE username IS NOT NULL能确认是否集中在 RMAN 进程
BACKUP AS COMPRESSED BACKUPSET 没压缩，但内存占用反而升高
常见误判：以为加了
COMPRESSED就省资源，实际它只是声明意图，不改变元数据处理逻辑若未配置
CONFIGURE COMPRESSION ALGORITHM 'BASIC'，RMAN 仍走非压缩路径，但部分内部结构（如块头映射表）可能因算法协商多占内存缓冲更关键的是：压缩开关开启后，RMAN 会尝试更精细地识别已用块范围，这依赖段头和文件头元数据一致性检查——一旦 HWM 虚高或 ASSM 链路断裂，就会反复重试、缓存更多中间状态
SHOW COMPRESSION ALGORITHM必须返回'BASIC'才有效；设成'MEDIUM'或'HIGH'在磁盘备份中被静默忽略，但可能让内存管理器预留更多 buffer标准版（Standard Edition）下
AS COMPRESSED BACKUPSET直接不生效，也不报错，但 RMAN 仍按常规流程加载元数据，徒增开销
Linux 系统级 cache 堆积压垮 free 内存
RMAN 备份写本地磁盘时，Linux kernel 会把大量数据暂存在 pagecache 中，表现为
Cached内存飙升当
vm.min_free_kbytes过小（默认仅 64MB），系统来不及回收 cache，free内存跌至 0，触发 OOM killer 或彻底 hang 住vfs_cache_pressure=100是平衡值，但 RMAN 高频 inode/dentry 访问会让 cache 回收滞后实测有效参数：
vm.min_free_kbytes = 10428800（即 10GB）vfs_cache_pressure = 200（加速回收 directory/inode cache）修改后可用内存稳定在 8–10GB 区间，不再归零
临时表空间和系统 cache 是两层独立压力源，容易混淆。排查时先看错误类型：ORA-01652 指向数据库 TEMP，system hang / OOM killer 日志 指向 OS cache。两者都可能在同一个 RMAN 任务里先后爆发，但根因不同，不能靠扩 TEMP 或清 cache 单边解决。
