必须显式在run块中allocate channel，仅configure device type disk parallelism仅设上限不自动生效；漏写、路径冲突或未顶格大括号将触发rman-01009或退化为单通道。
必须显式在 RUN 块中 ALLOCATE CHANNEL，仅靠 CONFIGURE DEVICE TYPE DISK PARALLELISM 不会自动启用多通道；漏写或路径冲突会导致 RMAN-01009 或退化为单通道。
ALLOCATE CHANNEL 必须写在 RUN { } 里
RMAN 19c 不会把 CONFIGURE DEVICE TYPE DISK PARALLELISM 4 当作“默认执行 4 个通道”，它只是设了个上限。真正备份时仍需手动声明：ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/bak/ch1/%U'。否则报 RMAN-01009（语法错误），本质是大括号不匹配或缺少通道声明。
常见错误写法：
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;后直接BACKUP DATABASE;→ 报错或静默退单通道 -
RUN { ALLOCATE CHANNEL c1 ...; }中大括号没顶格、中间有空行或缩进 → 同样触发RMAN-01009 - 先
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/bak/%U';，又在 RUN 里重复ALLOCATE CHANNEL c1→ 通道名冲突，报RMAN-06017
每个通道必须绑定独立物理路径
所有通道指向同一本地目录（如 /bak）不是并行，是排队——文件系统锁、NFS lease timeout、磁盘队列争用全来了。真实 I/O 并发依赖路径隔离。
- SSD 或 ASM 环境：用不同子目录，如
FORMAT '/bak/ch1/%U'、FORMAT '/bak/ch2/%U' - RAC 环境：路径必须是共享存储（ASM 磁盘组或挂载的 NFS），不能用节点本地路径
- 别混用
DISK和SBT_TAPE通道在同一BACKUP命令中，RMAN 无法统一调度，部分通道会长时间空等
并发数不是越多越好，4 是安全起点
每个 ALLOCATE CHANNEL 启一个服务器进程，吃 PGA、归档读取上下文、控制文件锁。超了硬件承载能力，反而引发 enq: cf - contention 或 LGWR 延迟。
- 初始设 4：查瓶颈先跑
SELECT event, time_waited FROM v$session_event WHERE sid IN (SELECT sid FROM v$session WHERE program LIKE '%rman%') ORDER BY time_waited DESC；若大量direct path write，说明磁盘写满；若是latch: cache buffers chains，说明 buffer cache 被压垮 - SSD 全闪存可试到 8，但必须配不同子目录，且确保
DB_RECOVERY_FILE_DEST_SIZE足够（FRA 空间不足会卡死多通道写） - ARCHIVELOG 备份需单独分配通道，不能复用 DATAFILE 通道；SYSTEM/SYSAUX 表空间建议固定用 1～2 通道，避免控制文件更新冲突
RAC 环境下必须显式 CONNECT 到具体实例
RMAN 默认用 / as sysdba 连接，随机落到某个节点，所有通道挤在一台上，I/O 和 CPU 瓶颈立刻出现。跨节点并行的关键是每个 ALLOCATE CHANNEL 都带 CONNECT 子句。
ALLOCATE CHANNEL c1 DEVICE TYPE DISK CONNECT 'sys/ora@racdb1' FORMAT '/bak/ch1/%U';- 目标必须是
tnsnames.ora中定义的静态实例别名（如racdb1），不是 SCAN 地址（如racdb_scan） - 没加
CONNECT，哪怕配置了 8 个通道，也只在一个节点起进程
真正生效的标志不是日志里写了“allocated channel c1–c4”，而是查 V$BACKUP_SYNC_IO 中 DEVICE_TYPE 出现多个不同值，且 BYTES 增长速率接近；RAC 下还要确认 GV$PX_SESSION 各节点都有 Q00x 进程在跑。路径、连接、释放三者缺一不可，少一步就白配。
