ALLOCATE CHANNEL 并发数并非越多越好，过多会引发LGWR延迟、控制文件争用等；应据I/O或CPU瓶颈合理设置，初始建议4个，SSD环境上限8个，且需显式分配与释放通道。
ALLOCATE CHANNEL 的并发数不是越多越好
rman 备份速度卡在 i/o 或 cpu 上时，加通道看似能提速，但实际常适得其反。oracle 会为每个 allocate channel 分配独立的服务器进程、内存（如 pga）、归档日志读取上下文，通道数超过底层存储吞吐或实例负载能力后，反而引发争用——比如 lgwr 写延迟升高、控制文件写入排队、甚至出现 enq: cf - contention 等等待事件。
实操建议：
- 先查当前备份瓶颈：
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 限速；如果是latch: cache buffers chains，说明并发已压垮 buffer cache 管理 - 初始通道数设为磁盘阵列 LUN 数 × 2（非 SSD）或 CPU 核数 ÷ 2（SSD/全闪存），上限不建议超 8；生产环境首次调优从
ALLOCATE CHANNEL FOR BACKUP DEVICE TYPE DISK PARALLELISM 4;起步 - 避免在
BACKUP DATABASE中混用不同DEVICE TYPE通道（如同时分配DISK和SBT_TAPE），RMAN 无法统一调度，部分通道会长时间空等
手动 ALLOCATE CHANNEL 比 CONFIGURE CHANNEL 更可控
CONFIGURE CHANNEL 是全局默认配置，一旦设置，所有后续 RMAN 命令（包括 DELETE OBSOLETE、CROSSCHECK）都可能意外触发通道分配，导致资源被长期占用或与备份窗口冲突。
实操建议：
- 备份脚本中显式写
ALLOCATE CHANNEL ch1 DEVICE TYPE DISK FORMAT '/backup/db_%U';，完成后紧跟RELEASE CHANNEL ch1;—— 这样通道生命周期完全由脚本控制，不会残留 - 若需多通道，必须显式命名（
ch1,ch2…），不能重复使用同一名称，否则报错RMAN-06017: channel string is already allocated - 不要对同一物理路径用多个通道写入（如都写
/backup/），容易触发文件系统锁或 NFS lease timeout；应按子目录分流：FORMAT '/backup/ch1/db_%U',FORMAT '/backup/ch2/db_%U'
ARCHIVELOG 备份必须单独分配通道，且不能共享 DATAFILE 通道
RMAN 在 BACKUP DATABASE PLUS ARCHIVELOG 中会自动切换归档日志备份阶段，但如果之前只分配了 DATAFILE 专用通道（比如绑定了 MAXPIECESIZE 或特定 FORMAT），归档日志阶段可能因无可用通道而降级为单通道，拖慢整体耗时，甚至因归档日志未及时备份导致 ORA-19625（标识归档日志不存在）错误。
实操建议：
- 明确分离通道用途：用
ALLOCATE CHANNEL arch_ch DEVICE TYPE DISK FORMAT '/archbk/%U';专管归档，再用ALLOCATE CHANNEL db_ch DEVICE TYPE DISK FORMAT '/dbbk/%U';管数据文件 - 归档通道无需高并发（通常 1–2 个足够），重点是保证它存在；可配合
SQL 'ALTER SYSTEM ARCHIVE LOG CURRENT';提前触发归档，避免备份时卡在 log switch - 如果使用 FRA（Fast Recovery Area），
BACKUP ARCHIVELOG ALL DELETE INPUT阶段仍需独立通道——FRA 清理动作本身不走 RMAN 通道，但备份归档日志必须走
并行度在恢复时几乎不生效，别指望它加速 RESTORE
ALLOCATE CHANNEL 的并发设置对 RESTORE 几乎无加速作用。Oracle 恢复过程受控于数据文件头校验、块校验、重做应用顺序，这些是强串行逻辑；即使开了 8 个通道，RMAN 实际只用 1–2 个线程读取备份集，其余空转等待。
实操建议：
- 恢复前优先确认备份集完整性：
VALIDATE BACKUPSET <code>xxx;，避免恢复中途才发现坏块，白白浪费并发资源 - 真正影响恢复速度的是
DB_FILE_MULTIBLOCK_READ_COUNT和存储层随机读性能，不是通道数；调高该参数（如设为 128）比加通道更有效 - 如果目标库是备库（DG），启用
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;后，归档应用本身就是多线程，此时 RMAN 通道配置完全无关
最易被忽略的一点：ALLOCATE CHANNEL 的 MAXOPENFILES 参数默认是 16，当备份大量小数据文件（如上千个 10MB 的表空间）时，这个值会导致频繁打开/关闭文件句柄，反而比减少通道数更慢——遇到这种情况，宁可少开通道，也要把 MAXOPENFILES 提到 64 以上。
