rman磁盘备份只能用basic压缩算法，因low/medium/high仅支持osb或第三方介质管理器；必须配置configure compression algorithm 'basic'且需企业版，as compressed backupset仅为声明意图，实际压缩须结合视图v$rman_backup_job_details中output_bytes_display显著小于input_bytes_display来验证。
磁盘备份只能用 BASIC 压缩算法
RMAN 磁盘备份（DEVICE TYPE DISK）不支持 LOW、MEDIUM 或 HIGH 算法，这些只在配合 Oracle Secure Backup（OSB）或第三方介质管理器（如 NetBackup）时才生效。即使你执行了 CONFIGURE COMPRESSION ALGORITHM 'MEDIUM'，RMAN 也会静默忽略——SHOW COMPRESSION ALGORITHM 可能仍显示 MEDIUM，但实际没压缩。
实操建议：
- 必须显式执行
CONFIGURE COMPRESSION ALGORITHM 'BASIC'，这是磁盘环境下唯一真正起效的选项 -
BASIC基于 LZ77 变种，CPU 开销低，日常生产够用；压缩比通常 2x～3x，对含空字段、重复字符、未更新索引块的数据效果明显 - Standard Edition 不支持
BASIC压缩，即使写了AS COMPRESSED BACKUPSET也会被忽略，企业版（Enterprise Edition）是硬性前提
AS COMPRESSED BACKUPSET 不等于自动压缩
这个语法只是声明“我想压缩”，不是开关。它不触发任何算法，也不检查当前配置是否支持。常见错误是执行了 BACKUP AS COMPRESSED BACKUPSET DATABASE，但文件大小没变——根本原因就是 COMPRESSION ALGORITHM 没配对，或配了不支持的值。
实操建议：
- 不要依赖命令行临时加
AS COMPRESSED BACKUPSET来“试试看”，先确认CONFIGURE COMPRESSION ALGORITHM已设为'BASIC' - 如果已配置
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET，后续BACKUP DATABASE就自动带压缩，无需每次写AS COMPRESSED BACKUPSET - 验证是否真压缩，别看 .bkp 文件大小——文件系统压缩（ZFS/NFS）或稀疏写入会干扰判断，必须查
V$RMAN_BACKUP_JOB_DETAILS
怎么确认压缩真的起了作用？
关键指标只有两个：OUTPUT_BYTES_DISPLAY 显著小于 INPUT_BYTES_DISPLAY，且 COMPRESSION_RATIO > 1.0。文件大小不变 ≠ 没压缩，可能是高熵数据（加密列、频繁更新的事务表、归档日志）本身难压，也可能是上层文件系统压缩掩盖了 RMAN 层效果。
实操建议：
- 完备份后立即运行：
SELECT INPUT_BYTES_DISPLAY, OUTPUT_BYTES_DISPLAY, COMPRESSION_RATIO FROM V$RMAN_BACKUP_JOB_DETAILS WHERE START_TIME > SYSDATE - 1/24 ORDER BY START_TIME DESC; - 若
COMPRESSION_RATIO接近 1.0，先关掉 NAS/ZFS 的文件系统压缩再重试，排除干扰 - 注意：
NULL和UNUSED块跳过是默认行为，不属于二进制压缩，它们不改变COMPRESSION_RATIO，但会减少INPUT_BYTES_DISPLAY—— 所以真正反映 RMAN 压缩的是OUTPUT_BYTES_DISPLAY对比原始逻辑读字节数
压缩带来的代价不能忽略
启用 BASIC 压缩会增加 CPU 使用率（通常 +15%～30%），备份耗时略升（尤其在 I/O 不是瓶颈的环境），恢复时也要解压，比非压缩备份慢一点。它不是免费午餐。
实操建议：
- 在备份窗口紧张、CPU 资源吃紧的库上，优先保证完成率，而不是盲目开压缩
- 归档日志备份一般不建议压缩——本身变更量小、随机性强，压缩比常低于 1.1x，纯属白耗 CPU
- 如果存储成本远高于计算成本（比如云对象存储按 GB 计费），压缩收益明确，才值得长期开启
压缩是否生效，最终只取决于三件事：版本是企业版、算法配了 BASIC、查视图确认 OUTPUT_BYTES_DISPLAY 确实变小了。其余所有配置或命令，都是为这三点服务的。
