必须显式执行 ALLOCATE CHANNEL 才能启用并行备份，CONFIGURE DEVICE TYPE DISK PARALLELISM 仅设定通道数上限，不自动分配；漏写会导致单通道运行或 RMAN-01009 错误。
必须显式写 ALLOCATE CHANNEL，否则哪怕配了 CONFIGURE DEVICE TYPE DISK PARALLELISM 4，RMAN 仍只用单通道——它只是上限，不自动生效。
为什么 CONFIGURE DEVICE TYPE DISK PARALLELISM 不起作用
这个配置项只告诉 RMAN“最多允许用 4 个通道”，但不会在执行 BACKUP DATABASE 时自动分配。漏掉 ALLOCATE CHANNEL 就会退回到默认的 ORA_DISK_1 单通道，甚至报 RMAN-01009（语法错误），常见于大括号没顶格、RUN 块里缺声明或空行缩进错乱。
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 4是静态策略，仅影响后续ALLOCATE的最大可用数 - 真正并发靠的是
RUN { ALLOCATE CHANNEL c1 ...; ALLOCATE CHANNEL c2 ...; BACKUP ...; RELEASE CHANNEL c1; RELEASE CHANNEL c2; } - 若已用
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/path/%U'，又在 RUN 里重复ALLOCATE同名通道（如都叫c1），会触发RMAN-06017
如何正确写多通道 ALLOCATE CHANNEL
每个通道必须独立命名、绑定设备类型、指定写入路径，且路径不能重叠——尤其 NFS 或 Windows 共享目录下，多个通道写同一目录极易触发 lease timeout 或文件锁冲突。
- 通道名必须唯一：
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/bak/ch1/%U';，c2、c3类推 - 子目录必须分开：/bak/ch1/、/bak/ch2/…，不能全指向 /bak/
- 不要混用设备类型：一个
BACKUP命令里别同时分配DISK和SBT_TAPE，RMAN 调度失序，部分通道空等 - RAC 环境下每个
ALLOCATE必须带CONNECT子句，目标是 tnsnames.ora 中定义的**静态实例别名**（如racdb1），不是 SCAN 地址（如racdb_scan）
并发数设多少才合理
不是越多越快。每个通道独占 PGA、归档读上下文和控制文件锁资源，超限反而引发 enq: cf - contention 或 LGWR 延迟。
- 先查瓶颈：
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 已压垮 - 初始建议：普通磁盘阵列设 4，SSD/全闪存可试 8，但需配合不同子目录和足够 I/O 带宽
- 生产首次调优，从
ALLOCATE CHANNEL c1 ...到c4起步，观察v$session_event和系统负载再递增
手动 ALLOCATE 比 CONFIGURE CHANNEL 更安全
CONFIGURE CHANNEL 是全局默认，一旦设置，所有 RMAN 操作（包括 CROSSCHECK、DELETE OBSOLETE）都可能意外占用通道，导致备份窗口资源被长期锁死。
- 脚本中坚持显式写：
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/ch1/%U';，备份完立刻RELEASE CHANNEL ch1; - 避免用
CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G;后直接跑BACKUP，它可能被其他非备份命令误触发 -
ARCHIVELOG备份阶段必须单独分配通道，不能复用 DATAFILE 阶段的通道，否则归档日志备份可能卡住
最容易被忽略的是：RMAN 不会帮你判断底层存储是否真能撑住并发——它只管发任务。你得自己看 v$session_event、检查磁盘队列、确认 NFS lease 设置、验证每个子目录权限和空间，缺一不可。
