rman并行度需匹配实际i/o或cpu瓶颈，过高会引发enq: cf-contention、lgwr延迟等；通过v$session_event查等待事件定位瓶颈，i/o瓶颈优先优化存储路径并适度增通道，cpu或内存瓶颈则需降通道；传统阵列按lun数×2设并行度（上限6），ssd按cpu核数÷2设（如16核→8），asm需确保format路径对齐failgroup；生产环境推荐显式allocate/release channel而非configure，且归档日志备份需单独分配通道。
RMAN并行度不是设得越高越快，它必须匹配当前I/O或CPU的实际瓶颈点。盲目设成8甚至16，反而容易触发enq: cf - contention、LGWR延迟升高、控制文件写入排队等问题，备份耗时可能不降反升。
怎么判断当前备份卡在I/O还是CPU上？
执行备份前，先查RMAN会话的等待事件：
SELECT event, time_waited FROM v$session_event WHERE sid IN (SELECT sid FROM v$session WHERE program LIKE '%rman%') AND time_waited > 0 ORDER BY time_waited DESC;
重点关注前三项：
- 如果大量是
db file sequential read或direct path write→ 瓶颈在磁盘I/O，应优先优化存储路径、分散FORMAT子目录，再考虑适度加通道 - 如果出现
latch: cache buffers chains或library cache lock→ 并发已压垮内存或共享池，需降通道数，而非加 - 如果
DB CPU占比高且resmgr:cpu quantum频繁 → CPU饱和，通道数不应超过CPU_COUNT / 2
磁盘环境并行度推荐值怎么定？
别直接套“核数×2”这种模糊说法。真实配置要拆开看硬件层级：
- 传统SAS/SATA阵列：按LUN数量×2起步（例如4个LUN →
PARALLELISM 8），但上限不超过6；单LUN下设>2通道基本无效 - 全闪存/SSD/NVMe：按物理CPU核数÷2，例如16核 → 初始设
PARALLELISM 8，实测后可微调至6或10 - 使用ASM磁盘组：观察
v$asm_disk_iostat中各disk的reads/writes是否均衡；不均衡说明通道分配未对齐AU分布，需调整FORMAT路径到不同failgroup
CONFIGURE CHANNEL和ALLOCATE CHANNEL哪个更可控？
生产环境强烈建议用ALLOCATE CHANNEL显式控制，而不是依赖CONFIGURE CHANNEL全局设置。
原因很实际：
-
CONFIGURE CHANNEL一旦生效，所有RMAN命令（包括DELETE OBSOLETE、CROSSCHECK）都可能悄悄占用通道，导致备份窗口外资源被锁住 -
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/ch1/%U';+ 紧跟RELEASE CHANNEL ch1;，能确保通道只在真正需要时存在 - 多通道必须命名唯一（
ch1,ch2），重复用ch1会报RMAN-06017；且每个FORMAT必须指向不同物理路径，避免NFS lease timeout或ext4文件系统锁
最易被忽略的一点：归档日志备份阶段不会复用数据文件通道。哪怕你ALLOCATE CHANNEL ch1做了数据备份，BACKUP ARCHIVELOG ALL仍需单独ALLOCATE CHANNEL ch2——否则RMAN会在归档阶段卡住，等一个永远不会来的“空闲通道”。
