rman备份大文件表空间必须显式指定section size才能启用并行读取，否则即使分配多个通道也仅单通道工作；压缩算法选high/bzip2易致cpu瓶颈，应改用medium；通道数需按存储类型和cpu合理配置，虚拟环境须关闭write-back缓存。
大文件表空间没配SECTION SIZE，RMAN只能单通道扫完再扫下一个
RMAN对单个数据文件的并行读取能力，从11g起才靠SECTION SIZE解锁。没显式指定它，哪怕你ALLOCATE CHANNEL了4个，备份一个8GB的数据文件时，仍然只有1个channel在干活——其余3个干等着。这是11g之前“一个channel = 一个文件”的遗留行为，11g+只是加了分段机制，但不写SECTION SIZE就等于没启用。
常见错误现象：
-
v$session_longops里只看到1条full datafile backupset记录 -
sar -d或iostat -x显示磁盘util长期卡在单路峰值（比如只有sda在跑，sdb/sdc空闲） - 备份耗时跟只开1个channel几乎一样，通道数白配
实操建议：
- 先查目标文件大小：
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，该参数只支持BACKUP DATAFILE/BACKUP DATABASE/BACKUP TABLESPACE
压缩算法选HIGH或BZIP2，CPU吃满导致IO空转
大文件表空间备份本身I/O压力就大，再叠上COMPRESSION ALGORITHM 'HIGH'（12c+默认）或'BZIP2'（11g），CPU使用率很容易飙到90%+，而磁盘util却只有30%～40%。这时不是磁盘慢，是CPU在疯狂压缩，IO线程一直在等CPU吐出压缩块。
日志里看到compressed full datafile backupset，且elapsed time远大于实际I/O时间，基本就是CPU瓶颈。
实操建议：
- 改用
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';：压缩率2:1～3:1，CPU开销比HIGH低40%～60%，实测提速50%以上 - 顺手关掉
CONFIGURE BACKUP OPTIMIZATION OFF;：这个选项在压缩场景下容易引发元数据校验延迟 - 别全局设
HIGH或BZIP2——它们在OLTP或虚拟化环境里纯属负优化
通道数设太多，反而触发LGWR延迟和控制文件争用
给大文件表空间配8个channel，听着很猛，但Oracle内部资源调度扛不住。尤其当v$session_event里高频出现enq: CF - contention（控制文件争用）或latch: cache buffers chains，说明并发已经压垮了底层结构。
RMAN-06017报错、备份中途卡住、归档日志写入延迟变长，都是典型信号。
实操建议：
- 非SSD环境：按LUN数×2设初始通道数（如4个LUN → 最多8个channel）
- SSD/NVMe环境：按CPU核数÷2起步（16核 → 先试8个），生产环境建议从
PARALLELISM 4开始调 - 手动
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup1/%U';比CONFIGURE更可控，还能绑定不同物理路径，避免单点I/O拥塞 - 同一挂载点别开多个channel写——NFS lease timeout或文件系统锁会直接拖垮吞吐
虚拟机里没绕过hypervisor缓存，I/O路径被卡死
大文件表空间备份对I/O连续性要求高，而ESXi/KVM默认的write-back缓存策略会让RMAN写操作反复刷盘、等待确认。更糟的是，如果db_recovery_file_dest指向NFS/CIFS路径，backup as copy会把网络延迟完全暴露出来。
现象是：备份速度忽快忽慢、TIME_REMAINING波动剧烈、%us CPU不高但整体耗时很长。
实操建议：
- ESXi：检查.vmx中是否有
scsi0:0.writeThrough = "TRUE"，禁用write-back缓存 - KVM：QEMU磁盘设备用
cache=none或cache=directsync，不用cache=writeback - 确认
db_recovery_file_dest不指向NFS/CIFS——必须是本地ASM或直连PV SCSI设备 - 在VM内执行
cat /proc/cpuinfo | grep processor | wc -l确认真实vCPU数，parallelism不要超过它×1.2
真正卡住大文件表空间RMAN备份的，往往不是语法写错，而是SECTION SIZE没配、压缩算法硬套文档、通道数拍脑袋定、或者虚拟层缓存没关——这些点全得逐个验证，漏一个，调参就白忙。
