RMAN多通道恢复必须同步配置备份端SECTION SIZE拆分、恢复端CONFIGURE DEVICE TYPE DISK PARALLELISM持久化、存储层多路径隔离，缺一则并行失效，导致v$session仅1个RMAN进程活跃。
Oracle 19c RMAN恢复默认不并行，光改PARTITION或PARALLEL Hint没用——必须从备份生成、通道配置、存储路径三端协同，否则多通道只是“假并行”。
为什么ALLOCATE CHANNEL写了4个却只看到1个RMAN进程在干活
现象是RMAN日志里显示“allocated channel: c1”到“c4”，但v$session里只有1个RMAN会话活跃，v$backup_sync_io中DEVICE_TYPE也只出现一个值。根本原因不是命令没执行，而是I/O路径被锁死：
- 所有
ALLOCATE CHANNEL指向同一本地目录（如/backup），底层变成磁盘队列争用，不是并行是排队 - 没提前用
SECTION SIZE拆分备份集，导致RMAN只能让1个通道读完整文件，其余通道空等 - FRA空间不足（
DB_RECOVERY_FILE_DEST_SIZE太小），多通道写归档时触发空间等待，自动降级
必须同步改这3处配置，缺一不可
RMAN并行不是“配了就生效”的开关，而是一组强依赖配置。只改其中一项，其他项会把它拉回串行：
- 备份端就得支持：生成备份时加
SECTION SIZE 2G，例如BACKUP SECTION SIZE 2G TABLESPACE users；否则恢复时无法分片读取 - 恢复端要持久化并行：运行
CONFIGURE DEVICE TYPE DISK PARALLELISM 4，而不是每次手工ALLOCATE CHANNEL；否则新RMAN会话立即退化 - 存储层要隔离：为每个通道指定不同
FORMAT路径，例如FORMAT '/nfs1/...'%U'、FORMAT '/nfs2/...'%U'；挂载多个NFS或ASM磁盘组，避免路径冲突
parallel_max_servers设太高或太低都会拖慢恢复
这个参数不控制RMAN通道数，但决定后台PX进程能否及时响应。设错会导致恢复卡在“等资源”阶段：
- 设太小（如
parallel_max_servers = 4）：4个RMAN通道发起并行读写请求，但只有2个PX server可用，其余排队等v$px_session空闲 - 设太大（如>64）：大量PX进程抢占SGA和CPU，反而引发
enq: PS - contention或direct path read temp抖动 - 合理值 = 单次最大通道数 × 并发恢复任务数，例如同时恢复3个表空间、每路开4通道，建议设为
12～16
SYSTEM/SYSAUX表空间别乱开高并行
对核心系统对象强行并行，容易触发底层结构冲突：
- SYSTEM表空间恢复时开4通道，可能报
ORA-00600: internal error code, arguments: [kcrf_update_ckpt]，因控制文件更新争用 - SYSAUX中数据字典对象密集，高并行易引发
latch: cache buffers chains争用 - 稳妥做法：
SYSTEM和SYSAUX固定用ALLOCATE CHANNEL1～2个；用户表空间再放开
真正有效的并行恢复，从来不是堆通道数，而是让每个通道有独立I/O路径、能读独立数据段、背后有足够PX server承接——漏掉任意一环，v$recovery_slave里看到的STATUS就永远卡在WAITING。
