rman的rate参数仅在磁盘备份中通过allocate channel显式设置才有效，单位为字节/秒，不支持configure配置；sbt介质下常被mml绕过，需改用maxopenfiles或os层限速。
RMAN 的 RATE 参数是唯一能对单个备份通道做硬性 I/O 限速的机制，但它只在磁盘备份（DEVICE TYPE DISK）下可靠生效，且必须在 ALLOCATE CHANNEL 时显式指定——CONFIGURE CHANNEL 不支持该参数，设了也无效。
RATE 必须在 ALLOCATE CHANNEL 中设置，不能用 CONFIGURE
很多人误以为可以在全局配置里一次设定所有通道的速率，比如执行 CONFIGURE CHANNEL DEVICE TYPE DISK RATE 1048576，但 Oracle 会直接报错 RMAN-00571: RMAN-00569: Error messages...，因为 CONFIGURE CHANNEL 语法根本不接受 RATE。它只认 PARALLELISM、FORMAT 等有限参数。
正确写法只能是：
run {
allocate channel c1 device type disk rate 2097152; -- 2MB/s
allocate channel c2 device type disk rate 1048576; -- 1MB/s
backup database;
}
-
RATE值单位是字节/秒，填整数，不支持2M或2MB这类后缀 - 多个通道的限速是累加的：c1 + c2 = 总写入上限 3MB/s，不是“每个通道不超过 2MB/s”
- 一旦
run块结束，channel 自动释放，RATE设置即失效，下次备份需重写
磁盘 vs SBT：限速是否真正生效，取决于介质类型
如果你用的是磁带或云存储（如 Oracle Cloud Backup、NetBackup），底层走的是 SBT（System Backup to Tape）接口，那么 RATE 很可能被绕过。原因在于：RMAN 只控制“写入备份片”的节奏，而 SBT 的介质管理器（MML）常自带缓冲和异步提交逻辑，会把数据攒够再批量发出去，导致网络监控看到的流量远超 RATE 设定值。
典型现象：
- 设置了
RATE=524288（512KB/s），但iftop或交换机端口统计显示峰值达 15MB/s -
V$SESSION_LONGOPS里几乎看不到aggregate wait time，说明 RMAN 没被阻塞 - 备份耗时没明显延长，CPU 和 IO 等待也不升高
这时别怀疑配置错了——RATE 本身生效了，只是 MML 层没配合。你得联系备份软件厂商确认其是否支持 RMAN 的流控信号，或改用 OS 层限速（见下一条）。
SBT 场景下替代限速方案：MAXOPENFILES 和 OS 层干预
当 RATE 对 SBT 无效，又无法修改 MML 行为时，就得换思路：
-
MAXOPENFILES是通道级参数，控制并发打开的数据文件数，默认 8。调小到 2 或 4 能降低随机 IO 密度，间接缓解带宽压力，但对单一大数据文件（如 200GB 表空间）效果有限 - Linux 下可用
ionice -c2 -n7降 RMAN 进程 IO 优先级，再配合cpulimit限制 CPU 时间，削弱其调度权重 - 更彻底的是用
cgroups v1（如blkio.weight）直接限块设备吞吐，但这需要 root 权限，且 RMAN 完全无感知，容易因过度限制导致备份超时失败
注意：BACKUP AS COPY 完全不走 backup piece 流程，RATE 在这种模式下始终无效，别白费力气去试。
容易被忽略的兼容性细节
RATE 从 Oracle 10g 就存在，但早期版本（尤其是 AIX 上某些 SBT 插件）直到 12.1 才真正稳定支持。如果你用的是老系统，即使语法正确、日志没报错，实际限速也可能不准或抖动极大。
另一个坑是压缩：RMAN 按“写入备份片的字节量”计速，也就是压缩后的大小。如果你开了 COMPRESSED BACKUPSET，实际物理 IO 可能比 RATE 值低得多，但网络或磁盘写入压力未必同比例下降——因为压缩本身吃 CPU，解压恢复时又放大 IO 峰值。
