<p>根本原因是通道争抢底层I/O资源或CPU上下文切换开销压过了并行收益，表现为WAIT_TIME飙升、direct path write等待增多，或出现enq: cf - contention等争用事件。</p>
为什么RMAN通道数增加后IO吞吐没涨反降
根本原因不是“开了更多通道”，而是通道争抢底层I/O资源或CPU上下文切换开销压过了并行收益。典型表现是V$BACKUP_ASYNC_IO.TYPE = 'INPUT'的WAIT_TIME飙升，或V$SESSION_EVENT中大量direct path write等待；更隐蔽的是enq: cf - contention（控制文件争用）或latch: cache buffers chains——说明并发已超出buffer cache管理能力。
- 先查瓶颈：运行
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;，重点关注前3项 - 若
db file scattered read或direct path write占主导 → I/O是瓶颈，需检查存储实际吞吐是否被跑满 - 若
latch类或control file sequential read突出 → 并发过高，应减通道、调大DB_FILE_MULTIBLOCK_READ_COUNT - 不要只看
V$BACKUP_ASYNC_IO.EFFECTIVE_BYTES_PER_SECOND，它反映的是“已发出的写请求平均速率”，不等于设备真实带宽；要对比SELECT value FROM v$parameter WHERE name = 'disk_asynch_io';是否为TRUE，否则异步I/O未启用
ALLOCATE CHANNEL必须写在RUN块里，否则不生效
CONFIGURE DEVICE TYPE DISK PARALLELISM 4只是设了个上限，RMAN 19c起不会自动分配通道。漏掉RUN { }和其中的ALLOCATE CHANNEL，要么报RMAN-01009（语法错误），要么退化为单通道执行——这是生产环境最常踩的坑。
- 正确写法：
RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/bak/ch1/%U'; ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/bak/ch2/%U'; ALLOCATE CHANNEL c3 DEVICE TYPE DISK FORMAT '/bak/ch3/%U'; ALLOCATE CHANNEL c4 DEVICE TYPE DISK FORMAT '/bak/ch4/%U'; BACKUP DATABASE PLUS ARCHIVELOG; RELEASE CHANNEL c1; RELEASE CHANNEL c2; RELEASE CHANNEL c3; RELEASE CHANNEL c4; } - 大括号必须顶格，中间不能有空行或缩进空格，否则
RMAN-01009照报 - 每个
ALLOCATE CHANNEL必须命名唯一（c1、c2…），重复用c1会触发RMAN-06017 - 归档日志备份阶段需要独立通道：若
BACKUP DATABASE PLUS ARCHIVELOG中只分配了数据文件通道，归档阶段可能 fallback 到单通道；建议显式加ALLOCATE CHANNEL a1 DEVICE TYPE DISK FORMAT '/bak/arch/%U';并在归档阶段专用
多通道必须分流到不同物理路径，否则NFS/文件系统锁拖垮性能
多个通道往同一目录（如都写/bak/）会导致文件系统级锁竞争，尤其在NFS上极易触发lease timeout，表现为V$SESSION_LONGOPS中TIME_REMAINING剧烈波动、ELAPSED_SECONDS持续增长但无进度。
- SSD或全闪存环境可设4–8个通道，但必须绑定不同子目录：
FORMAT '/bak/ch1/%U'、FORMAT '/bak/ch2/%U'…，且这些路径应挂载在不同LUN或不同NVMe设备上 - 避免混用设备类型：
BACKUP命令中同时分配DEVICE TYPE DISK和DEVICE TYPE SBT_TAPE通道，RMAN无法统一调度，部分通道会长时间空等 - RAC环境下，每个
ALLOCATE CHANNEL必须带CONNECT子句指向具体实例别名（如CONNECT 'sys/ora@racdb1'），用SCAN地址（如racdb_scan）会导致所有通道挤在单节点 - 虚拟机中，确认
db_recovery_file_dest路径落在直连PV SCSI设备或ASM上，而非NFS/CIFS共享路径；否则BACKUP AS COPY会暴露明显延迟
RATE参数限速只对磁盘备份有效，且必须在ALLOCATE时指定
RATE是唯一能硬性限制单通道写入速率的机制，但它只作用于DEVICE TYPE DISK且必须随ALLOCATE CHANNEL一起写，CONFIGURE CHANNEL不支持该参数。设错位置或用在SBT场景，基本无效。
- 正确用法：
ALLOCATE CHANNEL c1 DEVICE TYPE DISK RATE=2097152 FORMAT '/bak/ch1/%U';（即2MB/s） - SBT备份（如Oracle Cloud、NetBackup）可能绕过
RATE，因介质管理器（MML）层缓冲行为不受RMAN控制；此时监控网络流量仍超标属正常 -
BACKUP AS COPY完全忽略RATE，因其不生成backup piece，走的是直接文件拷贝路径 - 限速生效时，
V$SESSION_LONGOPS中AGGREGATE WAIT TIME会上升，但不会报错；若CPU使用率低而耗时长，大概率是RATE在起作用
真正卡住RMAN IO吞吐的，往往不是“没开够通道”，而是通道之间在抢同一块磁盘、同一个NFS server、甚至同一个控制文件更新锁。分流路径、隔离资源、按实测瓶颈调参，比盲目堆数字重要得多。
