必须显式在run块中allocate channel并指定唯一名称与format路径，否则不生效；configure device type disk parallelism仅设上限，不自动分配通道，漏写将退单通道或报rman-01009。
ALLOCATE CHANNEL 必须写在 RUN 块里，否则不生效
RMAN 不会把 CONFIGURE DEVICE TYPE DISK PARALLELISM 4 当作“自动开 4 个通道”的指令——它只是声明上限。真执行时若没在 RUN { } 中显式分配，就会退回到单通道，甚至报 RMAN-01009（语法错误）。
常见踩坑点：
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 4;后直接写BACKUP DATABASE;→ 实际只用 1 个通道 -
RUN块内ALLOCATE CHANNEL缺少分号、大括号没顶格、中间多空格 → 触发RMAN-01009 - 先
CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/path/%U';，再在RUN里重复ALLOCATE CHANNEL c1 DEVICE TYPE DISK;→ 报RMAN-06017（通道已存在）
每个 CHANNEL 必须显式命名 + 指定 FORMAT 路径
通道名重复、路径冲突是备份失败最常见原因。RMAN 默认通道名（如 ORA_DISK_1）不能复用；多个通道往同一目录写，会触发 NFS lease timeout 或文件系统锁。
正确做法：
- 通道名唯一：
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;、ALLOCATE CHANNEL c2 DEVICE TYPE DISK; - FORMAT 必须带子目录隔离：
FORMAT '/backup/ch1/%U'、FORMAT '/backup/ch2/%U' - 用 ASM？直接写
FORMAT '+DG_BACKUP'即可，ASM 自动负载均衡，不用子目录
ARCHIVELOG 备份必须单独分配通道
BACKUP DATABASE PLUS ARCHIVELOG 看似一条命令，实际分两阶段：先备数据文件，再切归档日志。如果只分配了绑定了 MAXPIECESIZE 或固定 FORMAT 的 DATAFILE 通道，归档阶段会因通道不匹配失败。
安全写法：
- 在
RUN块中分阶段分配：ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/bak/db/%U';→ 备库；ALLOCATE CHANNEL ch2 DEVICE TYPE DISK FORMAT '/bak/arch/%U';→ 专用于BACKUP ARCHIVELOG ALL DELETE INPUT - 不要混用
DEVICE TYPE DISK和DEVICE TYPE SBT_TAPE在同一BACKUP命令中，RMAN 无法统一调度，部分通道会长时间空等
并发数不是越多越好，4 是安全起点，8 是 SSD 上限
每个 ALLOCATE CHANNEL 启一个服务器进程，消耗 PGA、归档读取上下文和控制文件锁。超了底层 I/O 或 CPU 承载能力，反而引发 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：
ALLOCATE CHANNEL c1 ...到c4，SSD 全闪存环境可试到 8，但必须配不同子目录 - RAC 环境下，每个
ALLOCATE CHANNEL必须带CONNECT子句，目标是 tnsnames.ora 中定义的静态实例别名（如racdb1），不能用 SCAN 地址（如racdb_scan）
真正容易被忽略的是通道生命周期管理：不显式 RELEASE CHANNEL，通道会一直占用会话与 PGA，后续 DELETE OBSOLETE 或 CROSSCHECK 可能悄悄拉起全部通道，导致资源卡死、备份脚本莫名失败。
