结论：对大于几百mb的数据文件，必须显式指定section size才能真正触发多通道并行备份；不加该参数，即使分配4个通道，rman也仅用1个通道处理整个文件，因11g前设计限制为“一个通道一次只能备份一个数据文件”，11g起通过分段（section）使多通道可并行读取同一文件的不同块范围。
直接说结论：对大于几百mb的数据文件，必须显式指定 section size 才能真正触发多通道并行备份；不加这个参数，哪怕分配了 4 个通道，rman 也只用 1 个通道处理整个文件。
为什么加了多个 channel 却没提速？
RMAN 在 11g 之前的设计限制是“一个通道 = 一个数据文件”，即使你 ALLOCATE CHANNEL c1 和 c2，备份单个大文件时仍只能串行走一个通道。11g 引入 SECTION SIZE 后才打破这个限制——它让 RMAN 把文件按块范围切分（section），每个通道负责其中一段。
常见错误现象：
- 执行
backup datafile 5;时，v$session_longops显示只有一个通道在full datafile backupset状态 - 监控磁盘 IO（如
sar -d）发现只有单路读取峰值，远低于物理盘能力 - 备份耗时与单通道配置几乎一致，通道数白配
SECTION SIZE 怎么设才合理？
核心原则：让总段数接近但不超过 256，且每段大小匹配底层存储吞吐能力。太小会引发调度开销，太大则无法充分利用通道数。
推荐做法：
- 先查目标文件大小：
SELECT bytes/1024/1024 AS mb FROM dba_data_files WHERE file_id = 4; - 若文件为 8GB（8192MB），想用 4 个通道：8192 ÷ 4 ≈ 2048MB → 设
SECTION SIZE 2G（注意单位支持M、G） - 若文件为 50GB，建议上限设到
SECTION SIZE 200M，RMAN 会自动调整为刚好 256 段（50*1024÷200 ≈ 256） - 避免设
SECTION SIZE 1M这类极小值——RMAN 会强制拉高到能凑出 256 段的大小，反而失去控制权
SECTION SIZE 只能在哪些命令里用？
它仅对 BACKUP DATAFILE、BACKUP DATABASE、BACKUP TABLESPACE 有效，不能用于 BACKUP AS COPY 或 BACKUP ARCHIVELOG。
典型正确写法：
RUN {
ALLOCATE CHANNEL c1 DEVICE TYPE DISK FORMAT '/bkp1/%U';
ALLOCATE CHANNEL c2 DEVICE TYPE DISK FORMAT '/bkp2/%U';
BACKUP SECTION SIZE 500M DATAFILE 4;
}
容易踩的坑：
- 误写成
BACKUP AS COPY SECTION SIZE 500M DATAFILE 4→ 报错ORA-19693: backup piece ... is not a multisection backup piece - 在
CONFIGURE中全局设置SECTION SIZE→ 不生效，该参数不支持持久化配置，必须在每次BACKUP命令中显式声明 - 指定大小超过文件本身（如文件 300MB 却设
SECTION SIZE 500M）→ RMAN 自动退化为单段备份，且不报错、不警告
怎么确认多段备份真的跑起来了？
执行完备份后，立刻查 LIST BACKUP OF DATAFILE 4，观察输出中是否出现多个 Piece Name 且 Pc#（Piece Number）从 1 开始连续编号。更重要的是看日志片段：
channel c1: backing up blocks 1 through 6400 channel c2: backing up blocks 6401 through 12800
这说明两个通道正在处理不同 block 范围。如果只看到一行 backing up blocks 1 through XXXXX，就说明 SECTION SIZE 没生效或被忽略。
最后提醒：SECTION SIZE 的价值集中在单个大文件上。如果你备份的是几十个百MB级小文件，加这个参数反而增加解析和调度负担，此时老老实实靠 FILESPERSET 和通道数更稳妥。
