并行备份卡在I/O的根本原因是读取路径未分散，多个RMAN通道争抢同一物理设备的磁盘寻道与缓冲区锁；需手动分配通道至独立存储路径，并启用块更改跟踪（BCT）避免全文件扫描。
为什么并行备份反而卡在I/O上
不是通道开得多就快，而是多个 rman 进程同时扫同一组数据文件时，会争抢磁盘寻道和缓冲区锁——尤其在机械盘或共享存储上，v$backup_sync_io.wait_time 明显升高、avg_wait_time 超过 10ms 就是典型信号。根本问题不在“并行”，而在“读取路径没分散”。
ALLOCATE CHANNEL 必须绑定独立物理路径
自动通道（CONFIGURE DEVICE TYPE DISK PARALLELISM）默认把所有通道都指向同一个挂载点，等于让4个工人挤在一条传送带上搬货。手动分配才能真正分流。
-
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup_nfs1/%U';→ 指向 NFS 存储 A -
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/backup_asm/%U';→ 指向 ASM diskgroup -
ALLOCATE CHANNEL c3 DEVICE TYPE DISK FORMAT '/backup_local_ssd/%U';→ 指向本地 NVMe 盘 - 禁用自动通道：
CONFIGURE DEFAULT DEVICE TYPE TO DISK;后再手动ALLOCATE，否则 RMAN 会忽略你的 FORMAT
数据文件分布影响读取并发度
RMAN 每个通道一次只读一个数据文件（除非启用 MAXPIECESIZE 分片），如果所有大文件都放在同一 ASM diskgroup 或同一 LUN 上，通道再多也绕不开底层 I/O 瓶颈。
- 查文件分布：
SELECT file_name, tablespace_name FROM dba_data_files; - 关键动作：把高 IO 表空间（如
USERS、UNDOTBS1）的数据文件分散到不同磁盘组或挂载点 - 不建议靠
DB_FILE_MULTIBLOCK_READ_COUNT调大来提速——它只影响单次读块数，对多通道争抢无缓解作用
块更改跟踪（BCT）未启用时，并行毫无意义
若 V$BLOCK_CHANGE_TRACKING.STATUS 是 DISABLED，RMAN 增量备份实际在全文件扫描比对 SCN，此时开 8 个通道 = 8 倍重复读，I/O 负载翻倍但有效吞吐几乎不增。
- 启用前先确认 BCT 文件路径不与归档日志或数据文件共用存储：
ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/bct/orcl_bct.f' REUSE; - BCT 文件本身要放在低延迟设备上（如 ASM 或本地 SSD），否则它自己就成了新瓶颈
- 首次
LEVEL 1备份仍慢——BCT 位图需构建，从第二次起才体现真实加速
