oracle 19c rman在并行控制、压缩算法、pdb粒度备份及验证机制上有实质性增强；需显式配置parallelism与通道分配，选用advanced压缩需对应许可，pdb备份须用backup pluggable database，验证推荐restore preview而非仅validate。
rman 在 oracle 19c 中不是“换了个壳”，而是关键路径上做了几处真实可测的提速和容错增强，尤其在并行控制、压缩策略、pdb 粒度操作和备份验证环节有实质性改进。
如何启用并行备份并避免 RMAN-01009 语法错误
Oracle 19c 默认仍只启用单通道，必须显式配置 PARALLELISM 并在 run 块中正确分配通道，否则手动写 allocate channel 会因缺少 { 触发 RMAN-01009 报错。
-
CONFIGURE DEVICE TYPE DISK PARALLELISM 3 BACKUP TYPE TO COMPRESSED BACKUPSET是全局生效的并行配置，但不自动分配通道 - 真正执行时仍需在
run { ... }中写明allocate channel c1 device type disk;等语句，且大括号必须成对、顶格、无空格干扰 - 若用
SECTION SIZE拆分大数据文件（如BACKUP DATAFILE 1 SECTION SIZE=100M），每个 section 会被独立调度到空闲通道，此时PARALLELISM值应 ≥ section 数量，否则部分 section 会排队等待
压缩算法选 BASIC 还是 ADVANCED？
BASIC 是 19c 的默认压缩算法，但实际压缩率有限；ADVANCED（需 Oracle Advanced Compression 选项许可）才能达到 50%+ 存储节省，且不影响 RMAN 恢复速度——因为恢复时无需解压，直接从压缩块读取。
-
CONFIGURE COMPRESSION ALGORITHM 'ADVANCED'必须在拥有对应许可的前提下设置，否则 RMAN 会静默回退到BASIC - 压缩发生在备份写入磁盘前，不增加 CPU 开销到生产实例（RMAN 进程自身承担）
- 归档日志也受该配置影响，
BACKUP ARCHIVELOG ALL同样被压缩，但DELETE INPUT不会因压缩而跳过未归档的 log
备份单个 PDB 时为什么不能用 BACKUP DATABASE
在 CDB 环境下，BACKUP DATABASE 总是备份整个容器数据库（含 root + 所有 PDB），哪怕你用 CONNECT TARGET sys@mypdb 登录。真要只备一个 PDB，必须用明确语法：
-
BACKUP PLUGGABLE DATABASE mypdb—— 最简方式，但要求 mypdb 处于OPEN或MOUNT状态 - 若 PDB 处于
UNPLUGGED或只读状态，RMAN 会报错ORA-65086: cannot access a pluggable database in this state - 不支持对 PDB 单独做
INCREMENTAL LEVEL 1，增量始终以 CDB 数据文件为单位，PDB 级别只能全备或基于时间点恢复
备份后立即验证是否可靠？VALIDATE 和 RESTORE ... PREVIEW 的区别
VALIDATE BACKUPSET 只校验备份集头部和块校验和，不读取实际数据块；而 RESTORE DATABASE PREVIEW 会模拟恢复路径，列出所有需要的备份片和归档日志，更贴近真实恢复场景。
-
VALIDATE BACKUPSET快，适合每日巡检，但无法发现归档日志断裂或控制文件版本不匹配问题 -
RESTORE DATABASE PREVIEW虽不真正还原，但会触发 RMAN 内部依赖解析，能暴露ARCHIVELOG DELETION POLICY配置不当导致的日志缺失 - 19c 新增
RESTORE TABLE支持，但仅限非 SYSTEM/SYSAUX 表空间中的普通表，且目标时间点不能跨 DDL（如TRUNCATE后无法恢复）
最容易被忽略的是：RMAN 自动备份控制文件的格式（CONFIGURE CONTROLFILE AUTOBACKUP FORMAT）如果没配绝对路径，在闪回恢复区（FRA）空间不足时，自动备份会失败且无明确报错，只留下 RMAN-03009 和 ORA-19809；务必确认 db_recovery_file_dest_size 足够，并定期清理旧备份。
