RMAN磁盘备份必须同时配置COMPRESS ALGORITHM 'BASIC'和AS COMPRESSED BACKUPSET才生效，仅写后者无效；'MEDIUM'/'HIGH'在磁盘备份中被静默忽略，且标准版不支持压缩。
能省空间，但必须配对生效——只写 as compressed backupset 不起作用，必须同时设置 configure compression algorithm 'basic'，否则备份文件大小几乎不变。
为什么 BACKUP AS COMPRESSED BACKUPSET 没变小？
常见错误现象：BACKUP AS COMPRESSED BACKUPSET DATABASE 执行成功，生成的 .bkp 文件和没加 COMPRESSED 时几乎一样大。
根本原因不是语法错，而是 RMAN 实际没调用压缩算法：
-
CONFIGURE COMPRESSION ALGORITHM没设，或设成了'MEDIUM'/'HIGH'—— 这些在纯磁盘备份（DEVICE TYPE DISK）下会被静默忽略 - 你用的是企业版（Enterprise Edition）吗？Standard Edition 下
AS COMPRESSED BACKUPSET直接被忽略，不报错也不压缩 - 底层文件系统已开启 ZFS/NFS 压缩，掩盖了 RMAN 自身是否生效，导致你误判
磁盘备份该配哪个 COMPRESSION ALGORITHM？
Oracle 12c+ 支持 'BASIC'、'LOW'、'MEDIUM'、'HIGH'，但磁盘备份仅认 'BASIC'。
实操建议：
- 执行
CONFIGURE COMPRESSION ALGORITHM 'BASIC';—— 这是唯一兼容磁盘备份的选项 -
'BASIC'基于 LZ77 变种，CPU 开销低，压缩比通常 2x～3x，适合日常生产 - 别试
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';——SHOW COMPRESSION ALGORITHM可能显示它，但实际不生效 - 验证当前配置：运行
SHOW COMPRESSION ALGORITHM;，再查V$RMAN_BACKUP_JOB_DETAILS中的COMPRESSION_RATIO
怎么确认压缩真的起了作用？
不能只看文件大小。RMAN 压缩是逻辑块级处理，同一数据多次备份体积可能不同；更关键的是 I/O 实际写入量。
执行完备份后，立即运行：
SELECT INPUT_BYTES_DISPLAY, OUTPUT_BYTES_DISPLAY, COMPRESSION_RATIO, STATUS FROM V$RMAN_BACKUP_JOB_DETAILS WHERE START_TIME > SYSDATE - 1/24 ORDER BY START_TIME DESC;
注意：
-
OUTPUT_BYTES_DISPLAY明显小于INPUT_BYTES_DISPLAY，才算 RMAN 级压缩成功 -
COMPRESSION_RATIO > 1.0表示有收益；≤ 1.0 说明基本没压（可能是高熵数据，如加密列、频繁更新的事务表） - 归档日志本身含大量随机变更，压缩比常低于 1.2x；而空字段多的表、未更新索引块，可达 3x～5x
配置 DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET 是必须的吗？
不是必须，但推荐显式配置。它让所有后续 BACKUP DATABASE 自动走压缩路径，避免每次都要写 AS COMPRESSED BACKUPSET。
注意两点：
- 这个配置和
CONFIGURE COMPRESSION ALGORITHM 'BASIC'必须成对出现，缺一不可 - 如果还配了并行度，例如
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET，那每个通道都会启用压缩，别漏掉算法配置 - 配置后记得验证：做一次小范围备份（比如单个表空间），立刻查
V$RMAN_BACKUP_JOB_DETAILS，别等全库备份完才发现没生效
最容易被忽略的是：压缩效果高度依赖数据可压缩性，而不是命令有没有写对。哪怕所有配置都正确，遇到大量加密 LOB 或已压缩归档日志，COMPRESSION_RATIO 也可能只有 1.05。这时候该检查的不是 RMAN 配置，而是业务数据特征。
