section size仅对大（>50gb）数据文件生效，必须配合显式allocate channel才触发多通道并行分段读取；对tempfile、undo、控制文件、归档日志无效，且值过小（如10m）会增加调度开销。
section size 不是“开了就快”的开关，它只对大文件有效，且必须配合显式并行通道才起作用。
SECTION SIZE 对哪些文件生效
只对 DATAFILE 有效，对 TEMPFILE、UNDO 表空间、控制文件、归档日志完全无效。如果你的数据库里 SYSTEM 或 USERS 表空间单个数据文件超过 50GB，不加 SECTION SIZE，哪怕开了 8 个通道，RMAN 也只会让一个通道读这个文件——其余 7 个干等。
- 典型场景：SYSTEM 表空间数据文件 120GB，未设
SECTION SIZE→ 实际并发度 = 1 - 同场景 +
SECTION SIZE=200M→ 切出约 600 个 section → 可被多个通道分摊调度 - 注意：
SECTION SIZE值不是越小越好；太小（如 10M）会显著增加元数据开销和 channel 切换成本
SECTION SIZE 和 ALLOCATE CHANNEL 必须配对使用
CONFIGURE DEVICE TYPE DISK PARALLELISM 4 只设上限，不自动分配通道；真正触发并行切片的是 RUN { ALLOCATE CHANNEL c1 ...; ALLOCATE CHANNEL c2 ... } 块里的显式声明。
- 漏写
ALLOCATE CHANNEL→SECTION SIZE被忽略，退化为串行备份 - 只写 2 个
ALLOCATE CHANNEL，但SECTION SIZE切出 600 个 section → 最多同时跑 2 个 section，其余排队 - 通道名重复（如两次
c1）→ 报错RMAN-06017，整个 RUN 块失败
CPU 高但备份慢？先看是不是 SECTION SIZE 没起效
常见现象：开启多个通道后，v$session 里看到大量 backup sync 状态会话，top 显示 CPU 占用高但磁盘读速只有 20MB/s —— 这大概率是大文件没分段，所有通道在争抢同一个文件的读锁。
- 查证方法：
SELECT file#, bytes/1024/1024 MB FROM v$datafile ORDER BY 2 DESC，看是否有 >50GB 的文件 - 验证是否生效：备份时开
TRACE或查v$rman_status，观察SECTION_SIZE列是否非空 - 关键动作：把
BACKUP DATAFILE 1改成BACKUP DATAFILE 1 SECTION SIZE=200M，别漏参数
最容易被忽略的一点：SECTION SIZE 不影响压缩、不改变备份集结构、也不减少归档日志扫描量——它只解决“大文件无法并行读”这一个卡点。如果 CPU 高来自归档日志密集扫描或压缩算法本身，得另调 COMPRESSION ALGORITHM 或关掉 rate 限速。
