SECTION SIZE 能加速归档日志备份，是因为它将所有待备归档日志按累计大小切片（如每500MB一片），使多通道可并发处理不同片段；而默认情况下RMAN对归档日志仅用单通道串行打包，即使分配多个channel也无效。
SECTION SIZE 为什么能加速归档日志备份
归档日志本身是小文件集合（每个通常几mb到上百mb），但 rman 默认把所有归档日志打包进一个备份集，只用一个通道串行处理——哪怕你开了8个 allocate channel，也只有一个在干活。这不是通道没起作用，而是 rman 的默认调度逻辑限制：单个备份集不支持多通道并行读取归档日志。
而 SECTION SIZE 强制将归档日志“按大小切片”，每片独立成段、可被不同通道并发拉取。只要归档目录里有足够多的归档文件（比如几百个），切片后就能真正跑满通道数。
- 归档日志总量大但单个文件小 → 不适合直接对单个归档文件设
SECTION SIZE（无效） - 必须配合
BACKUP ARCHIVELOG ALL或带时间范围的语句，且显式指定SECTION SIZE - 实际生效前提是归档日志已落盘、未被
DELETE INPUT清掉
怎么写有效的 SECTION SIZE 归档备份命令
不能直接在 BACKUP ARCHIVELOG 后加 SECTION SIZE ——语法不支持。正确做法是用 BACKUP BACKUPSET 或更稳妥的路径：先用 LIST ARCHIVELOG 确认待备范围，再用 BACKUP ARCHIVELOG LIKE + SECTION SIZE 组合。
推荐实操写法：
RUN {
ALLOCATE CHANNEL c1 TYPE DISK;
ALLOCATE CHANNEL c2 TYPE DISK;
ALLOCATE CHANNEL c3 TYPE DISK;
ALLOCATE CHANNEL c4 TYPE DISK;
BACKUP ARCHIVELOG ALL SECTION SIZE 500M;
}
注意：SECTION SIZE 500M 不是指每个归档文件切500M，而是 RMAN 把所有待备份归档日志按累计大小每500MB切一片，每片分配一个通道处理。所以归档越分散、总量越大，切片越多，并行度越高。
- 若归档总大小仅 200MB，
SECTION SIZE 500M实际只生成1个段，仍单通道运行 -
SECTION SIZE值不宜过小（如 10M），否则调度开销反超收益，还可能触发大量小文件 I/O - 必须确保
PARALLELISM≥ 预期最大切片数；可通过SHOW PARALLELISM查看，用CONFIGURE DEVICE TYPE DISK PARALLELISM 4设置
常见卡顿现象和对应检查点
加了 SECTION SIZE 还慢？大概率不是语法问题，而是环境卡点没排除。
-
RMAN-03009+ORA-19809：闪回区满，控制文件自动备份失败，间接阻塞归档备份流程 —— 先查V$RECOVERY_FILE_DEST，清空间或改CONFIGURE CONTROLFILE AUTOBACKUP FORMAT - 归档目录权限不对或 NFS 挂载延迟高：RMAN 读归档时卡在 open() 系统调用，表现为通道长时间 “waiting for archive log” —— 用
strace -p <pid></pid>抓 RMAN 进程验证 - 归档日志被其他进程（如 DataGuard 传输、手动
DELETE）锁住：V$ARCHIVED_LOG中DELETED = 'YES'但物理文件还在，RMAN 会跳过这些，导致实际备份量少、误判“快”，其实是漏了 - 归档日志跨多个
LOG_ARCHIVE_DEST_n，但只配了部分路径为LOCATION，其余是SERVICE：RMAN 默认只扫LOCATION类型，LIKE路径需对齐
SECTION SIZE 和归档删除策略的协同要点
加速备份后如果紧接着执行 DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1'，可能报 RMAN-08137: archived log not deleted, no valid checkpoint found。这不是 SECTION SIZE 的锅，而是归档删除策略未适配 19c 的新校验逻辑。
根本原因是：19c 要求归档删除前，该归档对应的 SCN 必须已被数据文件 checkpoint 覆盖，而旧版策略（尤其从 11g 升级来）默认没绑定有效目的地。
- 必须显式配置：
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY（如有备库）或TO BACKED UP 1 TIMES TO DISK - 确认归档目标状态：
SELECT DEST_NAME, TARGET, BINDING FROM V$ARCHIVE_DEST WHERE STATUS = 'VALID' - 删除前强制刷新检查点：
ALTER SYSTEM ARCHIVE LOG CURRENT; ALTER SYSTEM CHECKPOINT;
SECTION SIZE 解决的是“怎么更快把归档搬走”，但搬完之后要不要删、能不能删、删哪些，得靠归档删除策略兜底——这两者在 19c 里是解耦但强依赖的关系，漏配任何一个，都可能让备份流水线在最后一步卡住。
