RMAN备份CPU高主因是I/O争抢引发的上下文切换与压缩计算叠加，需禁用/降级压缩、限制通道写速、拆分归档与数据备份，并清除CONFIGURE CHANNEL全局配置以释放空转进程。
rman 备份期间 cpu 占用高，不是因为备份“太慢”，而是它在拼命抢 i/o 资源——而现代 linux/oracle 在高并发磁盘读+压缩+归档日志扫描时，cpu 会自然飙升。直接调 backup duration 并不能降 cpu，反而可能让 cpu 更持久地满载；真正该控的是 i/o 压力源头。
为什么 BACKUP DURATION + MINIMIZE LOAD 对 CPU 没用
MINIMIZE LOAD 只作用于 DEVICE TYPE DISK 通道，且它调节的是读取节奏（比如放缓 db file sequential read 频率），但不干预压缩、校验、归档日志解析这些 CPU 密集型环节。实测中，当 EFFECTIVE_BYTES_PER_SECOND 已接近磁盘上限（如 SSD 达 400MB/s），MINIMIZE LOAD 会让 RMAN 拉长读时间，导致 CPU 线程长时间处于“等 I/O 返回 + 处理块”的混合状态，%usr 和 %sys 双高。
常见错误现象：
- 执行
backup duration 01:00 minimize load database后，备份耗时从 25 分钟拖到 58 分钟，但top里oracle进程 CPU 持续 95%+ -
V$SESSION_LONGOPS显示OPNAME = 'RMAN backup & recovery'的TIME_REMAINING波动剧烈，说明 I/O 调度不稳，CPU 反复唤醒处理中断
真正有效的 CPU 降温三招
CPU 高本质是 I/O 带来的上下文切换 + 压缩计算叠加。要拆解，就得分别控住这俩头：
- 禁用压缩：如果没启用
AS COMPRESSED BACKUPSET，就别加；若业务强依赖压缩，改用ALGORITHM 'BASIC'（11g 默认）而非'MEDIUM'，后者 CPU 开销翻倍 - 限制单通道写速：
ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE 15M—— 这会强制降低缓冲区填充频率，间接减少 CPU 调度压力；实测在 SATA 阵列上设 10–20 MB/s，CPU 使用率可从 90%↓ 到 60% 以下 - 拆开归档与数据文件备份：
BACKUP DATABASE和BACKUP ARCHIVELOG ALL合并在一个 RUN 块里，会导致归档日志扫描和数据文件读取争抢 buffer cache latch；分开执行并显式RELEASE CHANNEL，能避免 latch: cache buffers chains 尖峰
CONFIGURE CHANNEL 是 CPU 隐形推手
11g 默认开启 CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/path/%U'，这个配置会让每个新连接的 RMAN session 自动分配通道并常驻 PGA。即使你没跑备份，V$PROCESS 里也会看到多个 ora_*_xxx 进程空转，持续消耗 CPU 周期做 channel 心跳检测。
正确做法：
- 清掉全局配置：
CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR - 所有备份都用显式
ALLOCATE CHANNEL+RELEASE CHANNEL包裹，确保资源即用即放 - 检查残留：
SELECT PROGRAM FROM V$SESSION WHERE PROGRAM LIKE '%rman%'，若有非活动态 rman 进程，手动 kill
最易被忽略的一点：11g 的 MINIMIZE LOAD 不感知归档日志生成速率。如果备份窗口内恰逢大批量事务提交（比如每分钟切 2GB 归档），RMAN 仍会高频扫描 V$ARCHIVED_LOG 视图，这部分 SQL 解析+硬解析本身就会吃 CPU——此时限速必须落到 OS 层（如 cgroups 限 oracle 用户 CPU quota）或改用 BACKUP ARCHIVELOG FROM TIME 'SYSDATE-1/24' 缩小扫描范围。
