rman 无 concurrent 关键字，其并发通过 allocate channel 或 configure parallelism 实现；自动并行仅在未手动分配通道时生效，实际并发受磁盘io、归档速度与内存等硬限制约束。
rman 的 concurrent 操作不是独立命令，而是通过多通道（allocate channel）实现的并发控制机制；它本质是并行备份/恢复，不是“同时执行多个 backup 命令”这种表面并发。
为什么 RMAN 不提供 CONCURRENT 关键字？
RMAN 语法中根本不存在 CONCURRENT 这个关键字——这是常见误解。用户在文档或脚本里看到的 CONCURRENT，往往来自误读 Oracle 官方手册中对“concurrent backups”的描述性用语（指“可同时运行多个独立 backup 作业”），或混淆了 Data Pump 的 PARALLEL / CONCURRENT 选项。
真实可用的并发控制手段只有：ALLOCATE CHANNEL（手动分配）或 CONFIGURE DEVICE TYPE ... PARALLELISM（自动通道调度）。
- 执行
BACKUP DATABASE;默认只用 1 个通道，即使数据库有 8 个数据文件，也是串行扫描 - 显式
ALLOCATE CHANNEL c1 DEVICE TYPE DISK;+ALLOCATE CHANNEL c2 DEVICE TYPE DISK;后再 backup，RMAN 才真正启动两个服务进程并行读取不同文件段 - 若未
RELEASE CHANNEL，后续 backup 命令会复用已有通道，但不会自动扩增
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 到底管什么？
这个配置只影响“自动通道分配行为”，不等于强制开启 3 个通道干活。它的作用边界很具体：
- 当执行
BACKUP DATABASE;且未手动ALLOCATE CHANNEL时，RMAN 自动启用 3 个磁盘通道 - 若已手动
ALLOCATE CHANNEL c1和ALLOCATE CHANNEL c2，则此配置被忽略 - 并行度 ≠ 实际并发数：若目标库只有 2 个数据文件，RMAN 可能只用 2 个通道，哪怕 PARALLELISM 设为 4
- 每个通道独占 PGA 内存（默认约 4MB/通道），设过高会导致 ORA-04030（内存耗尽）
并发备份时最容易被忽略的三个硬限制
并发不是开越多通道越好，实际受底层资源强约束：
-
DB_FILE_MULTIBLOCK_READ_COUNT影响单次 I/O 块数，值过小会让多通道争抢磁盘头，反而比单通道慢 - 快速恢复区（
DB_RECOVERY_FILE_DEST）所在磁盘吞吐量是瓶颈：若所有通道都写入同一块 SATA 盘，IO 队列深度打满，WAIT_EVENT会大量出现direct path write - 归档日志必须可用：并发 backup 过程中若触发日志切换，而归档进程（ARCn）跟不上，会卡在
log file switch (archiving needed)等待事件上
怎么验证当前 backup 是否真正在并发执行？
别只看 RMAN 输出里的 “allocated channel: c1” —— 那只是声明，不是运行证据。要确认真实并发，得查动态视图：
- 执行中查：
SELECT sid, serial#, program, event FROM v$session WHERE program LIKE '%rman%';—— 应看到多个rman@... (TNS V1-V3)进程，且event不同（如一个在db file sequential read，另一个在control file sequential read） - 备份完成后查：
SELECT start_time, end_time, input_bytes, output_bytes, status FROM v$rman_backup_job_details ORDER BY start_time DESC;—— 若input_bytes接近总数据量且end_time - start_time显著小于单通道预估时间，才是有效并发 - 注意：
v$rman_status中的operation字段显示BACKUP，但不区分单/多通道，不可依赖
真正决定并发效果的，从来不是你写了几个 ALLOCATE CHANNEL，而是磁盘带宽、归档吞吐、以及控制文件中 control_file_record_keep_time 是否足够长——否则备份元数据还没写完就被覆盖，后续 restore 就会找不到记录。
