CONFIGURE DEVICE TYPE DISK PARALLELISM 是控制 RMAN 备份磁盘通道并发数的核心配置，决定自动分配通道数量；设为 0 回退默认（通常为 1），设为 1 表示串行，手动 ALLOCATE CHANNEL 会覆盖该配置且不持久。
CONFIGURE DEVICE TYPE DISK PARALLELISM 是控制并发数的主开关
真正决定 rman 备份并发通道数量的，是 configure device type disk parallelism 这个配置项。它不是“建议值”，而是 rman 在执行 backup database 等命令时自动分配通道的默认依据。
常见错误现象：SHOW ALL 显示 PARALLELISM 1，但实际备份日志里看到 4 个通道在跑 → 很可能你之前用 ALLOCATE CHANNEL 手动分配过，而手动分配会覆盖 PARALLELISM 配置，且不持久。
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 3表示后续未显式ALLOCATE CHANNEL的备份，RMAN 自动启 3 个 DISK 通道 - 设为
0不代表“禁用并发”，而是回退到 Oracle 默认行为（通常是 1）；设为1才是明确串行 - 该设置只影响 DISK 类型；若同时用磁带（SBT_TAPE），需单独配
CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM
ALLOCATE CHANNEL 会绕过 PARALLELISM，且不推荐在常规备份中混用
手动 ALLOCATE CHANNEL 适合调试或特殊场景（比如给归档日志单独绑通道），但一旦用了，就等于放弃 PARALLELISM 的统一调度逻辑。
容易踩的坑：
- 在
RUN { ALLOCATE CHANNEL ...; BACKUP DATABASE; }中混用不同DEVICE TYPE（如一个 DISK、一个 SBT_TAPE）→ RMAN 无法协调读写节奏，部分通道空等，整体耗时反而更长 - 只给 DATAFILE 分配了通道，却执行
BACKUP DATABASE PLUS ARCHIVELOG→ 归档日志阶段因无可用通道降级为单通道，可能触发ORA-19625 -
ALLOCATE CHANNEL c1 DEVICE TYPE DISK MAXPIECESIZE 2G后没写RELEASE CHANNEL c1→ 通道不会自动释放，下次连接可能复用旧通道导致参数错乱
并发数不是越多越好：先看瓶颈再调
盲目提高 PARALLELISM 值，常引发资源争用而非提速。关键得先定位当前卡在哪。
查真实瓶颈的 SQL：
SELECT event, time_waited FROM v$session_event WHERE sid IN (SELECT sid FROM v$session WHERE program LIKE '%rman%') AND time_waited > 0 ORDER BY time_waited DESC;
典型信号：
- 大量
db file sequential read或direct path write→ 磁盘 I/O 到顶了，加通道只会让队列更长 - 出现
enq: cf - contention或latch: cache buffers chains→ 控制文件或 buffer cache 被压垮，说明并发已超实例承载力 -
log file sync时间飙升 → LGWR 写不过来，高并发备份加剧归档压力
MAXPIECESIZE 和 PARALLELISM 的配合关系常被误解
MAXPIECESIZE 控制的是每个备份片（.bkp 文件）大小，和并发数无关；PARALLELISM 控制的是同时写几个备份片。两者叠加，才决定总输出压力。
举个例子：
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 4+CONFIGURE CHANNEL 1 DEVICE TYPE DISK MAXPIECESIZE 2G→ 最多同时生成 4 个接近 2G 的文件，瞬时写入带宽翻 4 倍 - 但若底层存储是单块 SATA 盘，4 个并发写会把随机 IO 搞成满负载，实际吞吐可能还不如 2 个通道稳
- 更稳妥的做法：先用
PARALLELISM 2+MAXPIECESIZE 4G测试，再根据 I/O wait 和备份耗时决定是否加通道
真正难调的从来不是数字本身，而是理解「当前存储能扛住几个并发写」和「实例 PGA/控制文件锁能否撑住」之间的平衡点。设高了，日志里全是等待事件；设低了，备份窗口又不够——得拿 v$session_event 的数据说话，而不是拍脑袋。
