RMAN在12c中默认按“一个通道=一个数据文件”调度，未设SECTION SIZE时即使分配多个通道也仅用1个通道备份单个大文件；SECTION SIZE必须显式指定且仅对BACKUP DATAFILE/TABLESPACE/DATABASE有效，需置于run{}内backup子句中。
不加 SECTION SIZE，哪怕分配 4 个通道，RMAN 也只用 1 个通道备份单个超大文件——这是 11g 以前的设计限制，12c 没改，必须显式指定才能并行。
为什么 backup datafile 5 耗时长，v$session_longops 却只显示一个通道在跑
根本原因是 RMAN 在 12c 中仍默认按“一个通道 = 一个数据文件”调度。即使你 ALLOCATE CHANNEL c1 到 c4，只要没配 SECTION SIZE，它就不会切分文件，而是让其中一个通道独占读取整个文件。
- 现象：监控
sar -d或存储 IO，只看到单路磁盘读峰值，远低于物理能力 - 验证方式：
SELECT opname, sofar, totalwork FROM v$session_longops WHERE opname LIKE '%backup%';—— 若totalwork是文件总块数，但只有 1 行且sofar缓慢增长，基本可断定未分段 - 注意：
BACKUP AS COPY和BACKUP ARCHIVELOG不支持SECTION SIZE，加了也忽略
SECTION SIZE 怎么设才不白配、不翻车
目标是让 RMAN 实际生成的段数接近你分配的通道数，同时避开硬限制（最大 256 段）和调度开销（段太小反而拖慢）。
- 先查文件大小：
SELECT bytes/1024/1024/1024 AS gb FROM dba_data_files WHERE file_id = 5; - 若结果是 40GB，想用 4 个通道 → 理论每段 10GB，但 RMAN 要求段数 ≤ 256，40×1024÷10240 = 4，刚好 → 可设
SECTION SIZE 10G - 若文件是 60GB，硬算 60×1024÷256 ≈ 238MB → 直接设
SECTION SIZE 200M，RMAN 会自动调整为 256 段，不踩坑 - 绝对避免
SECTION SIZE 1M或10M：RMAN 会强制拉高到能凑出 256 段的值，你失去控制权，且调度开销飙升 - 如果设的值 > 文件大小（比如文件 8GB 却写
SECTION SIZE 10G），RMAN 直接退化为单段，SECTION SIZE失效
在哪写 SECTION SIZE 才生效
它只能出现在 BACKUP DATAFILE、BACKUP TABLESPACE、BACKUP DATABASE 这三类命令中，且必须放在 run{} 块内，作为 BACKUP 子句的一部分。
- 正确写法：
run { allocate channel c1 device type disk; backup datafile 5 section size 2G; } - 错误写法：
configure channel c1 device type disk section size 2G;——SECTION SIZE不是通道配置项，不能放CONFIGURE里 - 错误写法：
backup as copy datafile 5 section size 2G;——AS COPY不支持，语法通过但被忽略 - 多文件场景下可混用：
backup tablespace users section size 1G, tablespace tools;—— users 表空间走分段，tools 不分
真正容易被忽略的是：RMAN 对段数的隐式修正逻辑——你以为设了 SECTION SIZE 50M 就真按这个切，其实只要计算出段数 > 256，它就悄悄改成更大的值，连 warning 都不报。所以务必先算好目标段数，再反推 SECTION SIZE，别依赖“越小越细粒度”的直觉。
