RMAN备份CPU高主因是I/O争抢、压缩与归档解析三重叠加，而非速度慢；大文件未设SECTION SIZE导致串行读、CONFIGURE CHANNEL常驻PGA空转及压缩算法过重（如MEDIUM）进一步加剧CPU负载。
为什么RMAN备份CPU高不是因为“太慢”，而是I/O争抢+压缩叠加
rman备份期间cpu持续95%+，通常不是它干得少，而是干得太“挤”：一边疯狂抢磁盘i/o（触发大量上下文切换），一边同步做压缩、校验、归档日志解析——三者叠加，cpu自然飙高。实测中，backup duration 01:00 minimize load反而让cpu更持久满载，因为它拉长了“等i/o + 处理块”的混合状态时间，%usr和%sys双高。
- 典型现象：
v$session里大量backup sync状态会话，iostat -x 1显示%util100%，但磁盘实际读速只有20MB/s - 根本卡点常在大文件串行读：单个
DATAFILE>50GB，没配SECTION SIZE，8个通道也只让1个读，其余干等 -
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT是隐形推手——它让RMAN session常驻PGA，空转心跳检测，V$PROCESS里能看到多个ora_*_xxx进程白占CPU
禁用/降级压缩比调DURATION更管用
压缩是CPU密集型操作，尤其ALGORITHM 'MEDIUM'在SATA盘+8核环境下，开销可能比'BASIC'翻倍；而MINIMIZE LOAD完全不干预压缩环节，只调读节奏。
- 若业务允许，直接去掉
AS COMPRESSED BACKUPSET或显式指定COMPRESSED BACKUPSET AS ALGORITHM 'BASIC' - 必须用压缩时，11g默认
BASIC已够用；12c起可试MEDIUM，但仅限NVMe+32核环境，否则先测top -H里rman线程CPU是否持续超80% -
BACKUP DATABASE PLUS ARCHIVELOG场景下，归档日志扫描本身也吃CPU，拆开执行（先BACKUP DATABASE，再BACKUP ARCHIVELOG ALL）能减少buffer cache latch争抢
SECTION SIZE只对大DATAFILE生效，且必须配ALLOCATE CHANNEL
SECTION SIZE不是全局加速开关，它只解决“单个数据文件太大导致无法并行读”这一个点。对TEMPFILE、UNDO、控制文件、归档日志完全无效。
- 先查大文件：
SELECT file#, bytes/1024/1024 MB FROM v$datafile ORDER BY 2 DESC，确认是否有>50GB的DATAFILE - 写法必须是：
BACKUP DATAFILE 1 SECTION SIZE=200M，漏掉SECTION SIZE=参数就退化为串行 -
CONFIGURE DEVICE TYPE DISK PARALLELISM 4只设上限，不自动分配通道；真正触发分段读的是RUN { ALLOCATE CHANNEL c1; ALLOCATE CHANNEL c2; ... }里的显式声明 - 值不是越小越好：
SECTION SIZE=10M会导致600+分片，元数据开销和channel切换成本反升
限速要控写，别控读；释放通道比加通道更重要
全备打满IO主因是顺序写爆存储瓶颈（如SATA阵列峰值250MB/s），盲目加通道只会抬高latch: cache buffers chains争用。节流关键在写入端，且必须避免隐式通道常驻。
- 用
RATE限单通道写速：ALLOCATE CHANNEL ch1 DEVICE TYPE DISK RATE 15M，实测SATA阵列设10–20MB/s，CPU可从90%↓到60%以下 - 别在
CONFIGURE CHANNEL里设RATE，否则CROSSCHECK、DELETE OBSOLETE等日常维护也跟着被限速 - 每个
ALLOCATE CHANNEL后务必RELEASE CHANNEL，尤其分开执行BACKUP DATABASE和BACKUP ARCHIVELOG时，避免channel空转耗CPU - 删掉全局
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT，改用RUN块内显式ALLOCATE，路径、格式、rate都可控
最易被忽略的点：CPU高未必来自备份逻辑本身，而可能是CONFIGURE CHANNEL残留的空转进程，或是大文件没分段导致通道闲置——先查V$PROCESS和v$datafile，再动手调参。
