oracle rman的advanced compression仅在企业版+sbt介质管理器环境下生效，磁盘备份中configure compression algorithm 'high'被静默忽略，压缩比维持1.0～1.2；启用需同时满足：企业版、已授权advanced compression选项、使用sbt_tape设备、配置兼容介质管理器、显式设置算法，且compression_ratio>3.0才表明高级压缩真正起效。
oracle rman 的 advanced compression 不是“开个开关就提升压缩比”的通用加速器——它只在企业版 + 介质管理器（如 oracle secure backup 或 netbackup）环境下才真正启用 low/medium/high 算法；纯磁盘备份（device type disk）下，advanced compression 对压缩比无任何影响。
为什么 CONFIGURE COMPRESSION ALGORITHM 'HIGH' 在磁盘备份中完全无效
Oracle 12c+ 虽然支持 'LOW'、'MEDIUM'、'HIGH' 等算法名称，但这些高级算法仅通过 SBT 通道调用第三方介质管理器时才生效。磁盘备份路径绕过了 Oracle 的压缩引擎入口，直接走文件系统写入，因此：
-
CONFIGURE COMPRESSION ALGORITHM 'HIGH';在DEVICE TYPE DISK下会被静默忽略，SHOW COMPRESSION ALGORITHM;可能仍显示HIGH，但V$RMAN_BACKUP_JOB_DETAILS.COMPRESSION_RATIO会稳定在 ~1.0～1.2（即基本没压） - 即使数据库已安装 Advanced Compression 选件（
SELECT * FROM v$option WHERE parameter = 'Advanced Compression';返回 TRUE），磁盘备份也不会调用其算法 -
BACKUP AS COMPRESSED BACKUPSET DATABASE;命令本身不触发 Advanced Compression，它只激活BASIC（LZ77 变种）或 fallback 到 unused block compression
如何确认你真正在用 Advanced Compression 级别压缩
必须同时满足以下全部条件，COMPRESSION_RATIO 才可能突破 BASIC 的 2x～3x 上限：
- 数据库为 Enterprise Edition，且已启用 Advanced Compression 选项（非 Standard Edition）
- 执行备份时使用
SBT_TAPE设备类型：CONFIGURE DEFAULT DEVICE TYPE TO SBT_TAPE; - 已配置并加载兼容的介质管理器（如 Oracle Secure Backup、NetBackup、Commvault），且其 agent 支持 Advanced Compression 接口
- 显式指定算法：
CONFIGURE COMPRESSION ALGORITHM 'MEDIUM';（注意：'HIGH'在部分旧版介质管理器中可能不被识别） - 验证依据不是 .bkp 文件大小，而是查
V$RMAN_BACKUP_JOB_DETAILS中的COMPRESSION_RATIO > 3.0且OUTPUT_BYTES_DISPLAY显著低于INPUT_BYTES_DISPLAY
磁盘环境想提高压缩比？别碰 Advanced Compression，改数据和配置
在纯磁盘备份场景下，Advanced Compression 是个无效依赖。真正可操作的压缩比优化点只有这些：
- 关闭文件系统级压缩（如 ZFS、NetApp、NFS 压缩），否则
OUTPUT_BYTES_DISPLAY无法反映 RMAN 自身压缩效果，容易误判 - 避免把归档日志和数据库一起备份：
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;中归档日志本身已是高熵数据，会拉低整体COMPRESSION_RATIO；应拆分为独立命令 - 检查表空间是否全为本地管理：
SELECT extent_management FROM dba_tablespaces WHERE tablespace_name = 'SYSTEM';必须返回LOCAL，否则 unused block compression 失效，连基础过滤都丢掉 - 确保
COMPATIBLE≥ 10.2：SELECT value FROM v$parameter WHERE name = 'compatible';，低于此值则连未使用块过滤都不运行 - 对高重复性业务表（如日志表含大量 NULL/空字符串），可考虑定期
ALTER TABLE ... SHRINK SPACE COMPACT;，提升块内数据密度，利于BASIC算法发挥
Advanced Compression 对备份性能的实际代价很具体
即便在 SBT 环境下成功启用了 'HIGH'，也要直面它的硬成本：
- CPU 使用率峰值上升 70%～100%，尤其在 OLTP 高并发时段可能引发争用，
top -Hp $(pgrep -f "rman.*target")可观察到单线程持续 95%+ 占用 - 备份耗时增加 50%～80%，不是线性增长——当 I/O 延迟 > 10ms 时，压缩线程常因等待 buffer 而空转，反而拖慢整体吞吐
- 恢复时间未必缩短：虽然备份集体积小，但解压需额外 CPU 时间；实测显示，从
HIGH压缩备份恢复 100GB 数据，比BASIC多花 12～18 分钟 -
COMPRESSION_RATIO高≠实际节省多：若源数据含加密列、随机 BLOB 或频繁更新的事务表，HIGH可能只比BASIC多压 5%～8%，却付出双倍 CPU 代价
Advanced Compression 的价值不在“默认开启就能省空间”，而在于特定场景下的可控权衡：比如夜间低峰期用 SBT + HIGH 备份冷数据仓库，或配合带库长期归档。把它当成磁盘备份的提速捷径，只会让 COMPRESSION_RATIO 数字好看，却掩盖了真实 I/O 和 CPU 开销。最常被忽略的一点是：V$RMAN_BACKUP_JOB_DETAILS 里 STATUS = 'COMPLETED' 不代表压缩生效，必须盯住 COMPRESSION_RATIO > 1.0 和 OUTPUT_BYTES_DISPLAY 这两个字段才作数。
