根本原因是压缩算法吃cpu、i/o路径变长或与虚拟化/存储协议不匹配；关压缩最有效，否则需换算法、调并行、设section size、禁用hypervisor缓存。
Oracle RMAN开启压缩后备份变慢，**根本原因不是RMAN本身卡顿，而是压缩算法吃CPU、I/O路径变长、或与虚拟化层/存储协议不匹配导致的资源争用**。直接关掉压缩往往最有效，但若必须保留压缩，得换算法、调并行、绕开瓶颈点。
为什么BZIP2或HIGH压缩会让RMAN备份“龟速”？
RMAN默认的BZIP2（10g/11g）或HIGH（12c+）压缩级别，会显著拉高CPU使用率，尤其在vCPU受限或未启用hugepage的环境中。你看到的“每秒只写4MB”，大概率是CPU在疯狂压缩，磁盘IO反而空转。
- 日志里出现
compressed full datafile backupset，且elapsed time远大于实际I/O时间 → CPU成为瓶颈 -
v$session_longops中TIME_REMAINING波动剧烈、ELAPSED_SECONDS持续上涨 → 压缩线程调度不均 - OS层
top或vmstat显示%us（用户态CPU）长期>80%，而磁盘util
改用MEDIUM压缩 + 禁用backup optimization
MEDIUM在11gR2+和12c+中是平衡点：压缩率约2:1～3:1，CPU开销比HIGH低40%～60%，实测备份耗时可降50%以上。同时BACKUP OPTIMIZATION在压缩场景下易引发元数据校验延迟，建议关掉。
- 执行：
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM'; - 执行：
CONFIGURE BACKUP OPTIMIZATION OFF; - 避免全局设
HIGH或BZIP2——它们在多数OLTP或虚拟化环境里纯属负优化
SECTION SIZE不配，再多channel也白搭
对单个>几百MB的数据文件，**不加SECTION SIZE，RMAN永远只用1个channel读整个文件**，哪怕你ALLOCATE CHANNEL了4个。这是11g前的设计限制，11g起靠分段打破，但必须显式指定。
- 查文件大小：
SELECT bytes/1024/1024 AS mb FROM dba_data_files WHERE file_id = 4; - 若为8GB，想用4通道 → 写
BACKUP SECTION SIZE 2G DATAFILE 4; - 若为50GB，设
SECTION SIZE 200M，RMAN自动切出≈256段，逼近并行上限 - 绝对别写
BACKUP AS COPY SECTION SIZE ...→ 报ORA-19693，SECTION SIZE只支持BACKUP DATAFILE/BACKUP DATABASE/BACKUP TABLESPACE
虚拟机里备份慢？先绕过hypervisor缓存和网络文件系统
ESXi/KVM虚拟机中，RMAN慢常因I/O被hypervisor缓存层卡住，或db_recovery_file_dest指向NFS/CIFS路径，导致backup as copy暴露网络延迟。
- ESXi：确认.vmx中有
scsi0:0.writeThrough = "TRUE"，禁用write-back缓存 - KVM：QEMU磁盘设备用
cache=none或cache=directsync，不用cache=writeback - 检查：
SELECT name, value FROM v$parameter WHERE name = 'db_recovery_file_dest';→ 必须指向本地ASM或PV SCSI直连盘，不能是挂载的NFS - 虚拟vCPU数为4 →
CONFIGURE DEVICE TYPE DISK PARALLELISM 4，别设成8，否则CPU ready time飙升
真正卡住RMAN压缩备份的，从来不是语法或权限，而是CPU没喂饱、I/O被缓存截胡、或SECTION SIZE忘写。这些点漏掉一个，调参就全白费。
