RMAN磁盘备份仅支持'BASIC'压缩算法，'LOW'/'MEDIUM'/'HIGH'需Advanced Compression许可且仅对介质管理器生效；启用二进制压缩必须显式使用AS COMPRESSED BACKUPSET。
压缩算法选哪个：LOW、MEDIUM 还是 HIGH？
RMAN 的 compression algorithm 不是“越高压缩越好”。LOW 适合 CPU 资源紧张但磁盘充裕的环境；MEDIUM 是多数生产库默认选择，压缩率与开销较均衡；HIGH 在 Oracle Enterprise Edition + Advanced Compression 许可下才可用，压缩率更高但 CPU 消耗显著上升——实测在高并发 OLTP 场景下可能拖慢备份吞吐。
确认当前数据库支持哪些算法，查 V$RMAN_COMPRESSION_ALGORITHM 视图：
SELECT algorithm_name, description FROM V$RMAN_COMPRESSION_ALGORITHM;
注意：BASIC（即空值+未使用块压缩）始终可用，无需额外许可；而 LOW/MEDIUM/HIGH 属于二进制压缩，依赖 Advanced Compression 选项。
启用压缩必须加 AS COMPRESSED BACKUPSET 吗？
是的。仅配置 configure compression algorithm 'MEDIUM' 不会自动生效——它只是设置“默认偏好”，真正触发二进制压缩必须在 BACKUP 命令中显式指定 AS COMPRESSED BACKUPSET。
常见错误现象：配置了算法但备份文件大小没变，就是漏了这个关键词。
-
BACKUP DATABASE;→ 不压缩（哪怕 algorithm 已设为 MEDIUM） -
BACKUP AS COMPRESSED BACKUPSET DATABASE;→ 触发二进制压缩 -
BACKUP AS COMPRESSED BACKUPSET PLUS ARCHIVELOG;→ 归档日志也压缩
镜像副本（BACKUP AS COPY）不支持二进制压缩，只做空值/未使用块过滤。
压缩对恢复性能的影响容易被低估
压缩备份集在恢复时需实时解压，这会延长 RESTORE 阶段耗时，尤其在低配服务器或高并发恢复场景下更明显。实测同等数据量下，AS COMPRESSED BACKUPSET 恢复比非压缩备份慢 15–30%。
如果你的 RTO（恢复时间目标）非常严格，且磁盘空间不是瓶颈，建议权衡是否启用二进制压缩。
另外注意：RESTORE 过程中无法跳过解压步骤——即使你用 SET DECRYPTION IDENTIFIED BY ... 解密，解压仍发生在解密之后。
备份集大小与压缩共存时的坑
当同时配置 MAXPIECESIZE 和压缩时，RMAN 会先压缩再切片。这意味着：
- 一个逻辑上 3GB 的数据文件，压缩后变成 1.2GB，仍会生成单个
.bkp文件（只要 ≤MAXPIECESIZE） - 若压缩后仍超限，RMAN 才拆成多个片——但每个片仍是独立压缩的，不可跨片解压
别指望压缩能“绕过” MAXPIECESIZE 限制；反过来，也不要误以为设了 MAXPIECESIZE 1G 就能控制压缩后总大小——它只约束单个备份片物理尺寸。
真正影响最终存储的是压缩算法 + 数据可压缩性 + MAXPIECESIZE 三者共同作用，上线前务必用真实数据集验证。
