Oracle 12c RMAN备份集异常增大主因是未跳过高水位线后空块，因HWM虚高或段管理配置不当致blocks_used远小于blocks，压缩退化为低效CPU压缩。
oracle 12c 备份集大小异常增加，大概率不是因为数据变多了，而是 rman 没有跳过高水位线（hwm）之后的未使用块——也就是说，compress for archive high 或 backup as compressed backupset 实际上没生效，rman 在“假压缩”。
为什么 RMAN 压缩不跳过空块？先查 BLOCKS_USED 和 HWM 状态
RMAN 默认只压缩“已用块”，但前提是它能准确识别哪些块真被用过。若表空间是 ASSM（自动段管理）且未启用 SEGMENT SPACE MANAGEMENT AUTO 的完整链路，或表启用了 ROW MOVEMENT 但没做 SHRINK SPACE COMPACT，HWM 可能虚高，大量块被标记为“已分配但未使用”。RMAN 无法穿透这种逻辑状态，只能按物理块扫描。
- 查真实已用块比例：
SELECT segment_name, blocks, blocks_used FROM dba_segments WHERE segment_name = 'YOUR_TABLE';—— 若blocks_used远小于blocks，说明存在大量未使用块 - 确认 HWM 是否可收缩：
ANALYZE TABLE your_table VALIDATE STRUCTURE CASCADE;后查v$segment_statistics中db block changes和logical reads是否匹配业务写入量 - 别信
dba_extents的 count：它只统计区（extent）数量，不反映块级碎片
COMPRESS 参数在 12c 中的实际行为差异
Oracle 12c 的压缩不是“对整个备份流做 gzip”，而是基于块元数据的智能跳过。是否跳过空块，取决于 RMAN 能否从数据文件头 + 段头中拿到可信的“已用块范围”。一旦这个链路断裂，COMPRESS 就退化为仅做 CPU 压缩（类似 gzip -1），体积几乎不变甚至更大（因压缩头开销）。
-
BACKUP AS COMPRESSED BACKUPSET DATABASE：依赖底层存储层的块有效性判断，不强制跳过空块 -
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG：归档日志部分仍压缩，但数据文件部分可能失效 -
CONFIGURE COMPRESSION ALGORITHM 'HIGH'：只影响压缩算法强度，不改变“是否扫描空块”的逻辑 - 真正起效的组合是：
BACKUP AS COMPRESSED BACKUPSET DATABASE+ 表空间启用DEFERRED SEGMENT CREATION=FALSE+ 定期执行ALTER TABLE ... SHRINK SPACE COMPACT
标准版无压缩功能？别让 expdp 干 RMAN 的活
如果你在用 Oracle 12c Standard Edition，expdp compression=all 报错不是 bug，是许可证限制。但这不意味着你该让 expdp 承担备份职责——它导出的是逻辑结构，不是可恢复的一致性镜像。当备份集体积暴涨时，混用 expdp + gzip 只会掩盖 RMAN 层的真实问题。
-
expdp导出的.dmp文件本身不含空块，所以压缩率高（如 8.5:1），但这和 RMAN 物理备份的“跳过空块”完全无关 - 用
gzip压缩 RMAN 备份集（backupset）效果极差：已压缩的备份流再压，通常只减 3–5%，反而拖慢 I/O - 真正该做的是：在 RMAN 备份前运行
ALTER DATABASE DATAFILE ... RESIZE收紧数据文件，或迁移至ASSM + AUTOALLOCATE表空间并重建关键大表
最常被忽略的一点：RMAN 不会主动 shrink 表或 resize 数据文件。它只忠实地备份磁盘上“可见”的块范围。哪怕你删了 90% 的数据，只要没手动推进 HWM 或回收空间，RMAN 就照单全收——压缩参数只是锦上添花，不是雪中送炭。
