oracle 11.1 dg在窄带宽下无法通过compression=enable启用实时压缩，因其仅对归档间隙修复生效；实时lgwr/async流需启用隐含参数_redo_transport_compress，但会显著增加cpu开销、需主备监听重载且兼容性无保障。
oracle dg在窄带宽环境下无法靠常规配置打开redo传输压缩——11.1版本中compression=enable只对归档间隙修复生效，实时lgwr/async流根本不会压缩；想让重做流真正压缩，必须碰隐含参数"_redo_transport_compress"，但代价明确：cpu开销上升、兼容性无保障、需主备监听重载。
为什么COMPRESSION=ENABLE在11g里基本不工作
你配了LOG_ARCHIVE_DEST_2='SERVICE=standby ASYNC COMPRESSION=ENABLE'，但只要没发生归档中断，这个设置就等于没起作用。原因很直接：
- 11.1的压缩逻辑只嵌在gap检测与修复路径里，LGWR进程发出的每条redo record都是明文
-
v$archive_dest_status里的COMPRESSION列显示ENABLED≠ 正在压缩，它只表示“该destination允许在gap场景下启用压缩” - 查
v$archive_gap，如果返回空，说明当前根本没触发压缩逻辑，哪怕参数全对也白搭
启用"_redo_transport_compress"的硬性条件
这不是开关一开就生效的功能，必须同时满足以下四点，缺一不可：
- 主库执行
ALTER SYSTEM SET "_redo_transport_compress"=TRUE SCOPE=BOTH（引号不能少） -
LOG_ARCHIVE_DEST_n中显式写COMPRESSION=ENABLE，设为DISABLE或不写就等于关 - 主库和备库都执行
lsnrctl reload，否则已有RFS连接仍用旧协议，新连接才协商压缩头 - 部分场景下
SCOPE=BOTH不能立即覆盖所有LGWR线程，生产环境建议重启实例确保100%生效
压缩效果完全取决于日志内容，不是网络或参数
别被“压缩降带宽”误导。Oracle 11g内部用的是轻量级LZ变种，只对特定模式敏感：
- 大量空块（如高
PCTFREE表、刚TRUNCATE后INSERT） - 连续零值（如未填充的LOB slot）
- 重复事务槽（如批量
INSERT INTO t VALUES (1,'a'),(2,'a'),(3,'a')）→ 实测可达2.5:1 - 含加密列（TDE）、SecureFiles LOB、随机更新的索引键、
UPDATE SET blob_col = :b1→ 基本不压缩，甚至因zlib调用引入额外延迟
v$archived_log.bytes是磁盘文件大小，blocks是解压后逻辑块数，二者不能相除算“本次压缩比”——Oracle不提供单次传输的压缩率统计口径。
验证压缩是否真正在跑，不能只看参数
最靠谱的方式只有两种：
- 查
V$ARCHIVE_DEST_STATUS：SELECT DEST_NAME, STATUS, TRANSMISSION_MODE, COMPRESSION FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2，正常应返回ASYNC和ENABLED；若为DISABLED说明配置未生效或被覆盖 - 抓包验证：
tcpdump -i any port 1521 -w dg_comp.pcap后，Wireshark过滤tcp.len > 1000 && tcp.payload，对比开启前后单个TCP包payload大小变化
容易被忽略的一点是：压缩是CPU换带宽，不是免费午餐。主库CPU已超70%时，"_redo_transport_compress"会让LGWR多一次zlib调用，可能拖慢redo write time；广域网实际利用率低于30%时，开压缩收益极小，还增加ORA-16705解压失败风险。
