RMAN备份I/O过高时，核心解法是显式在ALLOCATE CHANNEL中指定RATE参数限速，单位须带合法后缀（如15M），且需隔离备份路径、分 RUN 块执行数据文件与归档日志备份，并禁用隐式通道配置。
RMAN备份I/O过高，核心解法是显式用RATE参数限速，而不是依赖BACKUP DURATION或全局CONFIGURE CHANNEL——后者在12c+已失效，且容易残留空转进程。
ALLOCATE CHANNEL中必须带RATE参数才生效
RATE只在ALLOCATE CHANNEL命令中有效，写在CONFIGURE CHANNEL里会被忽略（12.1+已弃用该配置项的RATE支持）。它限制的是每秒写入备份片的字节数，单位必须带后缀：15M合法，15m或15MB会触发ORA-19566误报。
- 数值按实际磁盘能力设：SATA阵列建议
10M–20M，SSD可到30M–50M；设太高反而引发重试和超时 - 多通道总限速 ≈ 单通道
RATE× 实际并发数，但需确认底层存储能否支撑（如RAID5高并发小IO下，4×30M可能卡在80M） -
RATE对BACKUP AS COPY完全无效，因不走备份片流程
避免CONFIGURE CHANNEL导致的隐性I/O争抢
11g/12c默认启用CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/path/%U'，这会让每个新RMAN连接自动分配并常驻通道，即使没跑备份，V$PROCESS里也会看到多个ora_*_xxx进程空转，持续消耗CPU做心跳检测，间接加剧I/O调度压力。
- 生产脚本务必改用显式
ALLOCATE CHANNEL c1 TYPE DISK RATE 15M FORMAT '/backup/ch1/%U' - 执行完立即
RELEASE CHANNEL c1，避免通道被后续CROSSCHECK或DELETE OBSOLETE意外复用 - 不同通道写入路径要隔离，比如
/backup/ch1/、/backup/ch2/，防止文件系统锁或NFS lease timeout
归档日志与数据文件必须分开备份
把BACKUP DATABASE和BACKUP ARCHIVELOG ALL合在一个RUN块里，会导致归档日志扫描和数据文件读取争抢buffer cache latch，触发latch: cache buffers chains尖峰，I/O响应变慢且不稳定。
- 拆成两个独立
RUN块：先BACKUP DATABASE，RELEASE CHANNEL后再开新通道跑BACKUP ARCHIVELOG ALL DELETE INPUT - ARCHIVELOG阶段不能复用DATAFILE通道——若之前通道绑定了
MAXPIECESIZE或特定FORMAT，归档日志备份可能被迫降级为单通道 - 如果启用了block change tracking，限速后增量备份耗时会明显增加（跟踪文件读取不受
RATE约束），可临时ALTER DATABASE DISABLE BLOCK CHANGE TRACKING
真正难控的不是参数本身，而是存储层是否尊重RATE节奏——SBT介质管理器（如NetBackup、Oracle Cloud）可能缓冲并绕过限速，此时得切到OS层用ionice+cpulimit或cgroups v1干预，但RMAN自身无感知。
