RMAN的RATE参数强制限制单通道写入备份片的字节速率，单位字节/秒，须在ALLOCATE CHANNEL时指定，对磁盘备份有效，SBT可能绕过，压缩后大小计入限速，不适用于BACKUP AS COPY。
设置 BACKUP ... RATE 参数直接限制 RMAN 备份吞吐量
rman 的 rate 参数是唯一能对单个备份通道（channel）做硬性带宽限速的机制，它限制的是写入备份片（backup piece）的字节速率，单位是字节/秒。不是“建议值”，而是强制截断——超出部分会被阻塞，io 等待时间上升，但不会报错。
实操建议：
-
RATE必须在ALLOCATE CHANNEL时指定，不能在CONFIGURE CHANNEL中全局设置（该命令不支持RATE） - 数值填整数即可，例如
RATE=1048576表示 1MB/s；RMAN 内部按字节计，不识别1M或1MB这类后缀 - 若同时分配多个通道（如
ALLOCATE CHANNEL c1 RATE=2097152和c2 RATE=2097152），总限速是各通道之和，不是单通道上限 - 注意：限速只作用于写入备份片的过程，不影响控制文件读取、归档日志扫描或内存中压缩/加密阶段
RATE 对不同备份类型的实际影响差异
限速效果高度依赖备份对象和介质类型。对磁盘备份（DEVICE TYPE DISK）基本可靠；对 SBT（如 Oracle Cloud、NetBackup）则取决于介质管理器是否尊重 RMAN 的写节奏——有些会缓冲并绕过限速，导致实际带宽仍超标。
常见错误现象：
- 设置了
RATE=524288（512KB/s），但网络监控显示备份流量峰值仍达 20MB/s → 很可能用了 SBT 且 MML 层未配合限速 - 磁盘备份时 CPU 使用率很低，但备份耗时明显延长，
V$SESSION_LONGOPS显示大量aggregate wait time→ 限速生效，IO 在主动等待 - 使用
BACKUP AS COPY时RATE完全无效 → 正确：该命令不走 backup piece 流程，RATE不适用
替代方案：MAXOPENFILES 和系统级限速的适用边界
当 RATE 不起作用（比如 SBT 场景），或需要更细粒度控制（如限制随机 IO 次数而非吞吐量），就得换思路。
实操建议：
-
MAXOPENFILES是通道级参数，控制并发打开的数据文件数，默认为 8；调小可降低 IO 并发度，间接缓解带宽压力，但对大文件备份效果有限 - Linux 下可用
ionice -c2 -n7+cpulimit包裹 RMAN 进程，或用cgroups v1限速块设备 IO —— 但这属于 OS 层干预，RMAN 自身无感知，且需 root 权限 - Oracle 19c+ 可尝试
CONFIGURE BACKUP OPTIMIZATION ON配合已备份文件跳过逻辑，减少重复 IO，但不是带宽限速，别混淆
容易被忽略的兼容性与副作用
RATE 参数从 Oracle 10g 引入，但直到 12.1 才在某些平台（如 AIX 上的某些 SBT 插件）真正稳定生效。低版本或非标准介质库下，它可能被静默忽略，且不报任何警告。
关键细节：
- 启用
COMPRESSION ALGORITHM（如LOW）后，RATE仍按压缩前原始数据量计算？错。RMAN 按写入备份片的实际字节数限速，即压缩后大小 —— 所以高压缩比下，实际源端读取速率可能远超RATE值 - 如果备份过程中出现
ORA-19502: write error on file ...，且伴随OSD-04016，先检查磁盘空间和权限，再确认是否因RATE过低导致写入超时（尤其 NFS 挂载点） - 使用
RECOVERY WINDOW或REDUNDANCY策略时，RATE不影响保留策略判断，但可能让备份窗口（backup window）内无法完成全量，间接触发策略失败
限速这件事，核心永远是“谁在写、往哪写、写多快”——RATE 只管最后一环，前面两个环节没理清，光调这个参数容易白忙活。
