oracle 11.1 的重做传输压缩仅在归档日志间隙修复时生效，不压缩实时lgwr/async传输；compression=enable需advanced compression license授权，且压缩效果取决于日志内容特征而非参数配置。
oracle 11g 的重做传输压缩不能靠“开开关”就提升压缩率；它本身不提供可调的压缩算法或级别，实际压缩效果完全取决于日志内容特征和传输路径配置，盲目启用反而可能拖慢同步。
COMPRESSION=ENABLE 在 11g 中只对归档日志间隙修复生效
Oracle 11.1 版本中，LOG_ARCHIVE_DEST_n 参数里的 COMPRESSION=ENABLE 仅在 Data Guard 主动拉取缺失归档（即解决 archive gap）时起作用，不会压缩实时 LGWR/ASYNC 传输的重做流。这意味着：即使你配了 COMPRESSION=ENABLE，只要没发生归档中断、备库没报 ORA-01547 或 gap detected，这个参数就等于没运行。
- 验证是否真走 gap 修复路径：查
v$archive_gap，非空才说明当前压缩逻辑被触发 - 11.2 才真正支持全路径压缩（SYNC/ASYNC/ARCH），但你的版本是 11.1？别信文档里笼统写的“11g 支持”
- 想强制让 ASYNC 也压缩？得设隐含参数
_redo_transport_compress_all=TRUE，但该参数未公开支持，且需SCOPE=SPFILE+ 重启，生产环境慎用
压缩率由日志内容决定，不是由参数控制
Oracle 11g 的重做压缩底层用的是轻量级 LZ 类算法，对重复块、连续零值、空闲事务槽敏感——它不压缩加密列、LOB 大字段、随机写入的索引键，也不压缩已加密的表空间日志。所以：
- OLTP 系统里大量短事务 + 高比例空块 → 实测压缩率常达 2:1～3:1
- 批量插入 10GB CSV 到堆表、或日志里塞满
UPDATE ... SET blob_col = :b1→ 压缩率可能跌破 1.1:1，甚至因 CPU 开销导致传输 lag 反升 - 无法通过 SQL 或视图查到某次传输的具体压缩比；
v$archived_log的blocks字段是解压后块数，bytes是磁盘文件大小，二者不可直接比
带宽省不省，关键看是不是真卡在网卡上
很多 DBA 看到“压缩能降带宽”就急着开，结果发现 transport lag 没变、CPU 却涨了 40%。问题往往不在传输层：
- 先确认瓶颈：查
v$archive_dest_status中STATUS是否为VALID，ERROR列是否为空；再看v$dataguard_stats的transport lag和apply lag是否同步增长 —— 如果只有后者涨，说明是备库应用慢，开压缩毫无意义 - 主库 ARCH 进程写归档到慢盘（比如 NFS 或低 IOPS 本地盘）？这会导致归档积压，LGWR 被阻塞，压缩再快也救不了
- 备库 MRP 进程被长事务锁住？
v$managed_standby里看PROCESS为MRP0的STATUS是否长期APPLYING_LOG，SEQUENCE#是否停滞 - 网络本身丢包率 >0.1%？压缩会放大重传代价，此时关压缩 + 换稳定链路，比调参数更有效
11g 压缩必须配 Advanced Compression License，且无运行时开关
Oracle 明确将 COMPRESSION=ENABLE 归入 Advanced Compression Option（ACO）功能集，未购买该 license 时，即使参数设成功，实例启动时也会报 ORA-00439: feature not enabled: Advanced Compression，且不会写入 alert.log 明确提示——它只是静默忽略该属性。
- 检查许可状态：运行
SELECT * FROM v$option WHERE parameter = 'Advanced Compression';，返回TRUE才代表已授权 - 没有替代方案：不能用 RMAN 压缩归档来“模拟”重做压缩，RMAN 输出的
.bkp文件对 DG 传输完全无效 - 第三方 WAN 加速器（如 Riverbed）仍可用，但它工作在 OS 网络栈层，Oracle 层面不可见，也无法通过
v$dataguard_stats监控其效果
真正影响 11g DG 同步效率的，从来不是“压缩率数字”，而是归档生成是否及时、网络链路是否稳、备库资源是否够。压缩只是个窄带场景下的辅助手段，不是万能解药。尤其在 11.1 中，它连实时传输都不管，别把它想得太重。
