Oracle 12.1起支持_REDO_TRANSPORT_COMPRESS隐含参数，12.1–19c默认关闭，21c起对DIRECT模式默认启用；仅当网络带宽瓶颈且日志可压缩时有效，盲目启用会增加主库CPU开销。
压缩开关只在特定 Oracle 版本生效
oracle 12.1 之前不支持 _redo_transport_compress 隐含参数；12.1–19c 默认关闭，21c 开始默认启用（但仅对 direct 模式有效）。它不是万能加速器——只有当网络带宽成为瓶颈、且日志块本身可压缩（比如大量空闲块、重复 dml）时，压缩才有明显收益。盲目开启反而增加主库 cpu 开销，尤其在高并发事务场景下。
- 确认版本：
SELECT * FROM v$version;，低于 12.1 不要尝试 - 检查当前值：
SHOW PARAMETER _REDO_TRANSPORT_COMPRESS，注意它属于隐含参数，ALTER SYSTEM SET需加SCOPE=SPFILE并重启实例 - 压缩仅作用于 LGWR 进程发起的实时传输（即
LOG_ARCHIVE_DEST_n中SYNC或ASYNC+LGWR），ARCH 进程归档不参与
必须配合 VALID_FOR 和 NET_TIMEOUT 才能稳定生效
单纯设 _REDO_TRANSPORT_COMPRESS=TRUE 不会自动触发压缩——它依赖底层网络层实际使用压缩协议，而这个行为由 Data Guard 传输路径的配置细节控制。常见失效原因是：未设置 VALID_FOR 导致传输走 ARCH 路径；或 NET_TIMEOUT 过短，压缩过程超时后降级为明文重传。
-
LOG_ARCHIVE_DEST_2必须显式指定：VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，否则可能 fallback 到 ARCH 传输 - 建议设置
NET_TIMEOUT=120（单位秒），避免因压缩延迟触发断连重试 - 验证是否启用压缩：查
v$archive_dest_status中TRANSMIT_MODE应为LGWR，且STATUS为VALID；再查v$dataguard_stats中transport lag是否显著下降
压缩率不可控，且无法监控具体压缩比
Oracle 不提供 per-logfile 或 per-archived-log 的压缩率指标，v$dataguard_stats 和 ADRCI 日志里也找不到「压缩前/后字节数」字段。你只能通过对比网络流量（如 netstat -i 或交换机端口计数）和 v$archived_log 中 blocks * block_size 粗略估算，误差常达 ±30%。
- 典型压缩率在 1.3x–1.8x 之间（即节省 25%–45% 带宽），但全插入语句或加密表空间日志几乎不压缩
- 不要依赖压缩来掩盖低质量网络——如果丢包率 >0.1%，压缩反而加剧重传风暴
- 升级到 19c+ 后，可考虑用
COMPRESSION=ENABLE替代隐含参数（需搭配LOG_ARCHIVE_DEST_n的新语法），更可控也更易诊断
备库接收端不感知压缩，但需预留更多内存
压缩发生在主库 LGWR 写入网络缓冲区前，解压在备库 RFS 进程收包后立即完成，整个过程对 SQL Apply 或 Redo Apply 透明。但解压需要额外 PGA 内存，若 _REDO_TRANSPORT_COMPRESS=TRUE 且备库 pga_aggregate_limit 设置过低，RFS 可能报 ORA-04030 或出现 wait event: 'log file sync' 异常延长。
- 备库应确保
pga_aggregate_limit≥ 2GB（尤其在 16 核以上机器上） - 监控 RFS 进程内存：查
v$process中对应 SPID 的pga_used_mem，持续高于 500MB 需警惕 - 如果备库是物理 standby 且启用了
STANDBY_FILE_MANAGEMENT=AUTO，压缩不会影响文件管理逻辑，但首次同步大文件时仍可能因解压延迟导致ARCH wait on ATTACH
事情说清了就结束。真正卡住的往往不是参数开不开，而是主备两端的网络路径是否真走 LGWR、有没有静默丢包、以及备库内存是否被其他进程挤占——这些比调一个隐含参数难查得多。
