启用_REDO_TRANSPORT_COMPRESS需设置隐含参数"_redo_transport_compress"=TRUE并配合LOG_ARCHIVE_DEST_n的COMPRESSION=ENABLE，且主备库均需重载监听；12.1+默认关闭，仅18c+支持SYNC模式压缩，验证须查V$ARCHIVE_DEST_STATUS或抓包。
启用 _REDO_TRANSPORT_COMPRESS 需要改哪些参数
这个隐含参数本身不直接生效，必须配合 log_archive_dest_n 的 compression=enable 才起作用。oracle 12.1+ 默认关闭压缩，即使设置了隐含参数也没用。
-
ALTER SYSTEM SET "_redo_transport_compress"=TRUE SCOPE=BOTH;—— 必须加引号，且仅影响后续新建立的传输连接 -
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC COMPRESSION=ENABLE ...' SCOPE=BOTH;——COMPRESSION=ENABLE是开关，不是可选值；设为DISABLE或不写就等于关 - 主库和备库都要重启监听（
lsnrctl reload），否则部分 RFS 进程可能沿用旧连接配置
为什么开了压缩反而同步延迟变高了
压缩是 CPU 换带宽，不是免费午餐。尤其在主库 CPU 已经 >70% 负载时，_REDO_TRANSPORT_COMPRESS 会让 LGWR 线程多一次 zlib 压缩调用，可能拖慢日志写入节奏。
- 观察
V$SYSSTAT中compression cpu usage和redo write time是否同步上升 - 广域网带宽实际利用率低于 30% 时，开压缩收益极小，还增加解压失败风险
- 备库 RFS 进程解压出错会报
ORA-16705: unable to decompress received redo，此时需检查主备 zlib 版本是否一致（Oracle 内部用的是精简 zlib，不兼容系统级库）
不同 Oracle 版本对 COMPRESSION=ENABLE 的行为差异
12.1 引入该功能，但直到 19c 才真正稳定。关键区别不在压缩算法，而在连接协商机制。
- 12.1–12.2：只支持在
ASYNC模式下启用，SYNC或ARCH模式下忽略COMPRESSION - 18c+：支持
SYNC模式压缩，但要求主备都打 RU 补丁（如 18.10+），否则备库 RFS 无法识别压缩流头 - 所有版本都不支持在
LOG_ARCHIVE_DEST_STATE_n=DEFER状态下预加载压缩能力，必须先ENABLE后再设压缩
验证压缩是否真正在跑
不能只看参数，得抓真实网络包或查内部视图。最靠谱的是查 V$ARCHIVE_DEST_STATUS 的 TRANSMISSION_MODE 和 COMPRESSION 列。
-
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 大小变化（压缩后通常小 40%~60%，取决于 redo 内容重复度） - 注意：RMAN 备份压缩、
DB_SECUREFILE压缩、SECUREFILE LOB压缩和这个完全无关，别混
_REDO_TRANSPORT_COMPRESS 的实现藏得深，参数名带下划线只是表象，真正起效靠的是 LOG_ARCHIVE_DEST_n 子句里的 COMPRESSION 和底层网络握手信号。很多人配完发现没效果，问题往往出在没 reload 监听，或者版本补丁不齐导致协商失败。 
