查v$backup_async_io中effective_bytes_per_second是判断rman是否卡i/o的唯一可信指标：若仅达设备标称吞吐30%~50%，主因是通道数或并行度不足；若已逼近上限，则瓶颈在cpu或压缩。
查V$BACKUP_ASYNC_IO看I/O是否真跑满
别猜，直接查视图。RMAN是否卡在I/O，V$BACKUP_ASYNC_IO里EFFECTIVE_BYTES_PER_SECOND是唯一可信指标。如果这个值只有设备标称吞吐的30%~50%，基本就是通道数或并行度没开够；如果已逼近上限（比如SSD标称500MB/s，实测480MB/s），那瓶颈大概率在CPU或压缩上。
常见错误现象：RMAN backup & recovery I/O等待事件持续高占比，但磁盘iostat显示util很低——说明RMAN根本没把I/O打满，问题出在调度层而非存储本身。
- 执行前确保数据库处于
ARCHIVELOG模式，否则归档日志读取会阻塞备份主线程 - 查之前先
SELECT * FROM V$SESSION_LONGOPS WHERE OPNAME LIKE 'RMAN%';确认当前任务ID，避免查到历史残留记录 - Windows下注意权限：必须用Oracle服务账户运行SQL*Plus，否则
V$视图可能返回空
区分configure device type disk parallelism和default parallelism
这两个参数常被混用，但实际生效逻辑完全不同。CONFIGURE DEVICE TYPE DISK PARALLELISM 4是硬性上限，后续所有BACKUP命令最多只能起4个通道；CONFIGURE DEFAULT PARALLELISM 4只是“默认建议值”，若没显式ALLOCATE CHANNEL，RMAN才参考它——但最终仍受前者压制。
典型错误配置：设了DEVICE TYPE DISK PARALLELISM 2，又在脚本里写ALLOCATE CHANNEL c1 DEVICE TYPE DISK和ALLOCATE CHANNEL c2 DEVICE TYPE DISK，结果只起1个通道——因为RMAN认为“2个通道”是上限，而你没指定第二个通道的FORMAT路径，它自动合并为单通道执行。
- 手动
ALLOCATE CHANNEL时务必带FORMAT，例如：ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/backup/disk1/%U'; - Linux下多个通道指向不同挂载点（如
/backup/disk1和/backup/disk2）才能真正分散I/O压力 - 虚拟机环境要同步查宿主机CPU ready time，若>5%，
PARALLELISM值应≤可用vCPU数
识别压缩与CPU瓶颈的信号
启用AS COMPRESSED BACKUPSET后速度变慢，别急着调低压缩级别。先看V$SESSION_WAIT里是否有大量ON CPU或PGA memory operation等待——这是CPU饱和的明确信号。Oracle 19c默认COMPRESSION ALGORITHM 'MEDIUM'需约1.5核/GiB压缩量，4通道并发压20GB数据，就吃掉6核以上。
错误做法：看到慢就切回'BASIC'或关压缩，结果I/O队列暴涨，RMAN Disk slave I/O等待飙升。正确路径是先压测单通道压缩吞吐，再决定是否降级算法或减少并发。
- 临时验证CPU影响：加
SET COMMAND ID TO 'test_nocomp';后跑一次无压缩备份，对比V$SESSTAT中CPU used by this session增量 - 19c中
COMPRESSION ALGORITHM 'LOW'比'MEDIUM'快约40%，但压缩率下降15%~20%，适合vCPU紧张场景 - 禁用
BACKUP OPTIMIZATION（CONFIGURE BACKUP OPTIMIZATION OFF），虚拟环境中该功能常因元数据同步延迟引发误判
磁带备份必须验证MAXOPENFILES与MML协商结果
磁带场景下MAXOPENFILES不是RMAN内部参数，而是向介质管理器（MML）申请并发流的“签证”。设成8不代表MML真给8个流——NetBackup默认NUMBER_OF_STREAMS=4，CommVault可能限制更严。不匹配就会触发RMAN-03009 + ORA-19554，但错误日志里几乎不提MML侧拒绝原因。
最简验证法：备份前在RMAN中执行SHOW ALL;，确认CONFIGURE DEVICE TYPE SBT PARALLELISM与每个ALLOCATE CHANNEL ... MAXOPENFILES N的N值一致；再立刻查V$RMAN_OUTPUT里是否出现sbtio: stream count = X（X应等于你设的MAXOPENFILES）。
- 物理磁带驱动器数量是硬上限：1台LTO-7驱动器建议
MAXOPENFILES ≤ 3，否则机械臂寻道争抢严重 - 每个
MAXOPENFILES=1通道会额外占用约1MB PGA内存，设太高可能挤占_smm_max_size导致排序失败 - 若用
SECTION SIZE切分大文件，确保MAXOPENFILES ≥ SECTION COUNT / CHANNEL COUNT，否则section排队卡死
真实瓶颈往往藏在参数交集处：比如你设了PARALLELISM 6，但MAXOPENFILES只配了2，又忘了在ALLOCATE CHANNEL里显式声明——RMAN会默默退化为单通道执行，而你还在盯着V$BACKUP_ASYNC_IO等I/O跑满。
