根本原因是Oracle 12c RMAN在元数据同步阶段（如DELETE INPUT、REPORT OBSOLETE）执行隐式排序操作，触发大量TEMP空间消耗；相比11g的轻量级处理，12c默认启用更严格的跨视图关联查询（含ORDER BY/GROUP BY），且未走索引，导致临时段spill至CJCTEMP。
oracle 12c rman 备份期间临时表空间爆满，根本原因不是备份本身耗内存，而是元数据同步阶段执行的隐式排序操作大量占用 cjctemp（或 temp）空间，尤其在归档日志清理、备份集校验、控制文件快照生成等环节触发。
为什么 RMAN 在 12c 会突然猛占 temp 空间
12c 引入了更严格的备份元数据一致性检查机制，比如 DELETE OBSOLETE 或 PLUS ARCHIVELOG DELETE INPUT 执行时，RMAN 会内部调用类似 DBMS_RCVMAN 的包，在 V$RMAN_BACKUP_JOB_DETAILS 和控制文件之间做跨视图关联查询，这类查询常含 ORDER BY、GROUP BY、JOIN 操作，且未走索引——直接 spill 到 temp 表空间。
对比 11g：同样命令下，11g 多数元数据操作走轻量级哈希或内存缓冲；12c 默认启用更“严谨”的解析路径，导致 temp 使用量翻倍甚至更高。
- 典型触发点：
DELETE INPUT归档后自动清理、REPORT OBSOLETE、CROSSCHECK BACKUP - 错误日志里出现
RMAN-03002+ORA-01652且时间点卡在 “deleting archived logs” 或 “updating recovery catalog” 阶段，基本可锁定是元数据同步引发 - 临时表空间大小本身够用（如 5GB），但并发多个 RMAN session 时，每个 session 分配的 sort segment 可能叠加超限
怎么快速确认是不是排序类 temp 消耗
别只看 dba_temp_files 总大小，重点查正在撑爆 temp 的 SQL 和会话：
- 运行：
SELECT sql_id, temp_space_allocated/1024/1024/1024 gb, program, module FROM v$active_session_history WHERE sample_time > SYSDATE - 1/24 AND temp_space_allocated > 1024*1024*1024 ORDER BY temp_space_allocated DESC FETCH FIRST 5 ROWS ONLY; - 若返回的
sql_id对应语句含RCVJN_、RCVDF_、DBMS_RCVMAN前缀，或module是rman@+ 主机名，就是 RMAN 元数据操作 - 同时查：
SELECT * FROM v$tempseg_usage WHERE username IS NOT NULL ORDER BY segsize DESC;，确认是否集中在 RMAN 进程的SESSION_ADDR
临时缓解：绕过高开销排序的实操方法
不改参数、不扩空间也能压低 temp 占用，关键是拆解和抑制元数据同步强度：
- 把
DELETE INPUT拆成两步：先BACKUP ARCHIVELOG ALL，再单独跑DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-1'—— 后者不触发全量元数据比对 - 禁用恢复目录同步（如果只用控制文件）：
CONFIGURE CONTROLFILE AUTOBACKUP ON;+CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;，避免 RMAN 被迫频繁刷新 catalog 视图 - 对已知大归档量时段，手动预删旧归档：
DELETE ARCHIVELOG UNTIL SEQUENCE <xxx> THREAD 1;</xxx>，减少后续PLUS ARCHIVELOG的扫描压力 - 临时关闭块更改跟踪（如果启用了）：
ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;，该功能在 12c 中与 RMAN 元数据更新存在已知争用
长期修复：temp 表空间配置必须匹配 12c RMAN 行为
单纯加文件 size 不解决问题，关键要支持自动伸缩 + 分离负载：
- 必须设
AUTOEXTENSIBLE ON，且NEXT不低于 512M（12c 内部排序常一次申请 512M chunk）：ALTER DATABASE TEMPFILE '/oracle/CJC/cjcdata1/temp_1/temp.data1' AUTOEXTEND ON NEXT 512M MAXSIZE 30G; - 不要只依赖一个 temp 文件；添加第二个独立 tempfile 到不同磁盘路径，让 RMAN 并行通道能分散分配：
ALTER TABLESPACE CJCTEMP ADD TEMPFILE '/u02/oradata/CJC/temp_2.dbf' SIZE 10G AUTOEXTEND ON; - 监控阈值不能只看 80%：12c RMAN 的 temp spike 往往在 5–10 秒内冲到 95%，建议用
DBA_HIST_TEMPSTATXS做分钟级趋势预警，而非依赖单次v$tempfile查询
真正麻烦的不是 temp 空间不够，而是 12c 把元数据一致性检查塞进了 backup/delete 流程深处，且默认不暴露开关。一旦遇到 ORA-01652，优先怀疑是不是某条看似无害的 DELETE INPUT 或 REPORT 命令，正在后台默默发起全库级别的排序扫描。
