RMAN备份CPU高主因是I/O争抢与压缩叠加：磁盘读、归档扫描、压缩计算三者高并发导致上下文切换和CPU满载；禁用或降级压缩算法（如设为'NONE'或'LOW'）比调整DURATION更有效。
为什么RMAN备份CPU高，不是因为“太慢”而是I/O争抢+压缩叠加
rman备份期间top里oracle进程cpu持续95%+，通常不是备份逻辑本身慢，而是磁盘读、归档扫描、压缩计算三者在高并发下互相拉扯：大量上下文切换抬高%sys，压缩算法吃满核心拖高%usr。尤其当effective_bytes_per_second已逼近磁盘上限（如sata阵列实测220mb/s），rman仍在拼命调度，cpu就只能干等+处理+再等。
禁用或降级COMPRESSION ALGORITHM比调DURATION更有效
BACKUP DURATION 01:00 MINIMIZE LOAD对CPU降温基本无效——它只放缓读节奏，不碰压缩、校验、归档日志解析这些真·CPU密集环节。实测中该组合反而让CPU更持久地满载。
- 若未强依赖压缩，直接关掉：
CONFIGURE COMPRESSION ALGORITHM 'NONE'; - 若必须压缩，选
'LOW'或'BASIC'（11g默认），避免'MEDIUM'（CPU开销翻倍）和'HIGH'（单核吞吐可能跌破10MB/s） - 验证是否生效：
SELECT * FROM V$RMAN_CONFIGURATION WHERE NAME = 'COMPRESSION ALGORITHM';
用RATE限写速，比盲目加通道更能稳住CPU
加通道数量（PARALLELISM）不等于降CPU；当I/O已达瓶颈，多通道只会加剧latch: cache buffers chains争用和调度抖动。真正可控的切入点是限制每个通道的写入速度。
- 在
RUN块内显式声明：ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE 15M; - 不要在
CONFIGURE CHANNEL里设RATE，否则CROSSCHECK、DELETE OBSOLETE等日常命令也全被拖慢 - 从10–20 MB/s起步，结合
iostat -x 1观察%util是否回落至70%以下 - 配完立刻
RELEASE CHANNEL c1，避免空转进程持续消耗CPU周期
大文件不分段（SECTION SIZE），再多通道也白搭
如果v$datafile里有单个>50GB的文件（如SYSTEM表空间），但没加SECTION SIZE，RMAN会强制串行读——其余通道全程等待，CPU却仍在处理校验、归档扫描、内存拷贝等后台任务。
- 先查大文件：
SELECT file#, bytes/1024/1024/1024 GB FROM v$datafile ORDER BY 2 DESC; - 备份时显式切分：
BACKUP DATAFILE 1 SECTION SIZE=200M;（不能漏参数） - 必须配对
ALLOCATE CHANNEL：切出600个section，只开2个channel → 最多2个section并行，其余排队 -
SECTION SIZE对TEMPFILE、UNDO、控制文件、归档日志完全无效，别在这上面试
最容易被忽略的是CONFIGURE CHANNEL的隐式驻留行为：哪怕没跑备份，它也会让多个ora_*_xxx进程常驻PGA做心跳检测。执行CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;再重配，才能真正释放这部分CPU。
