RMAN全备慢主因是I/O或CPU瓶颈：若V$BACKUP_ASYNC_IO中EFFECTIVE_BYTES_PER_SECOND远低于设备标称值，系通道数不足；若接近上限则压缩/CPU成瓶颈。configure device type disk parallelism设设备级通道上限，configure default parallelism仅设默认值，实际取二者交集。并行度需匹配硬件能力，盲目调高反致争抢。建议从2起步，逐步增至4或6；手动ALLOCATE CHANNEL可绑定不同存储路径，避免单点I/O拥塞。
为什么 BACKUP DATABASE 跑得慢，先看瓶颈在哪
rman 全备慢不是单一原因，但最常卡在 i/o 或 cpu。如果备份目标是本地 ssd 或高速 san，v$backup_async_io 中 effective_bytes_per_second 明显低于设备标称吞吐量，说明 i/o 没跑满——大概率是通道数太少或并行度没开；如果值接近理论上限但整体耗时仍长，压缩或 cpu 成了瓶颈，尤其启用了 compress 时。
configure device type disk parallelism 和 parallelism 的区别必须分清
这两个参数都影响并发，但作用层级不同：
-
configure device type disk parallelism 4：为磁盘设备类型全局设定最多启用 4 个通道，后续每个backup命令默认按此数分配通道 -
configure default parallelism 4：仅控制 RMAN 自动分配通道的“默认数量”，不强制绑定设备类型；实际生效还受device type配置和资源限制约束 - 真正执行时，RMAN 会取两者交集——比如设了
device type disk parallelism 2，又在 backup 命令里写allocate channel c1 device type disk手动开 3 个，最终只起 2 个
并行度不是越高越好，要匹配硬件真实能力
盲目加大 parallelism 可能反拖慢速度：
- CPU 密集型操作（如启用
compression algorithm 'MEDIUM'）需要足够空闲核心，否则线程争抢导致上下文切换开销上升 - 磁盘 I/O 吞吐已达上限时，再增通道只会加剧队列等待，
V$BACKUP_ASYNC_IO.TYPE = 'INPUT'行的WAIT_TIME会明显升高 - 建议从
parallelism 2起步，观察V$SESSION_LONGOPS中OPNAME = 'RMAN backup & recovery'的进度波动，逐步加到 4 或 6，超过 8 很少带来收益
手动分配通道比全靠 configure 更可控
当需要差异化调度（比如归档日志走高速路径、数据文件走大带宽路径），用显式 allocate channel 更可靠：
rman target /
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/fast_backup/%U';
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/fast_backup/%U';
ALLOCATE CHANNEL c3 DEVICE TYPE DISK FORMAT '/slow_storage/%U';
BACKUP DATABASE PLUS ARCHIVELOG;
}
注意：FORMAT 必须在 ALLOCATE CHANNEL 里指定，不能只写在 BACKUP 后；且各通道路径最好物理隔离，避免单点 I/O 拥塞。
真正容易被忽略的是通道与存储路径的绑定关系——很多人调了 parallelism 却把所有通道指向同一挂载点，结果只是多进程抢同一个磁盘队列。
