不能直接用alter system set _redo_transport_compress=true生效，必须满足oracle 12.1+版本、advanced compression授权、lgwr传输路径、valid_for匹配、net_timeout≥120等全套条件，缺一不可。
不能直接用 ALTER SYSTEM SET _REDO_TRANSPORT_COMPRESS=TRUE 就生效——它只是个隐含参数开关，实际压缩是否触发，取决于传输路径、模式和配套配置是否全部对齐。
确认版本和许可前提
Oracle 12.1 是起点，低于这个版本压根不识别 _REDO_TRANSPORT_COMPRESS；12.1–19c 默认关闭，21c 起仅对 DIRECT 模式默认启用。你得先查清楚：
SELECT * FROM v$version;
另外，Redo Transport Compression 属于 Oracle Advanced Compression 选件，没买授权的话，即使参数设了也无效，ALTER SYSTEM 不报错但日志里会默默跳过压缩逻辑。
- 查当前值：
SHOW PARAMETER _REDO_TRANSPORT_COMPRESS（注意带下划线） - 设参数必须加
SCOPE=SPFILE并重启实例，MEMORY或BOTH无效 - 11g 第2版起支持显式
COMPRESSION属性（如LOG_ARCHIVE_DEST_2='SERVICE=boston COMPRESSION=ENABLE'），但 12c+ 推荐用隐含参数统一控制
必须走 LGWR 传输路径，且 VALID_FOR 要匹配
压缩只作用于 LGWR 进程发起的实时传输（即 SYNC 或 ASYNC + LGWR），ARCH 进程归档不参与。常见失效就是配置写成了 ARCH 模式却指望压缩生效。
-
LOG_ARCHIVE_DEST_2必须显式包含LGWR和VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 漏掉
VALID_FOR很容易 fallback 到ARCH路径，此时_REDO_TRANSPORT_COMPRESS完全不生效 - 示例正确写法：
LOG_ARCHIVE_DEST_2='SERVICE=boston LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'
NET_TIMEOUT 至少设为 120，否则压缩可能超时降级
压缩过程本身有 CPU 和时间开销，如果网络延迟波动大或 NET_TIMEOUT 太小，LGWR 在压缩未完成前就判定超时，会自动降级为明文重传——你看到传输正常，但其实没压缩。
- 默认
NET_TIMEOUT是 30 秒，对压缩场景明显不够 - 建议设为
120（单位秒）：LOG_ARCHIVE_DEST_2='... NET_TIMEOUT=120 ...' - 这个值不是越大越好，要结合专线抖动历史（比如你见过抖动导致延迟突增到 80 秒，那 120 就是合理底线）
- 同时检查
v$archive_dest_status中TRANSMIT_MODE确实是LGWR，STATUS是VALID
验证压缩是否真在跑，而不是“看起来开了”
Oracle 不提供压缩率指标，v$dataguard_stats 里没有「压缩前后字节数」字段，你只能靠间接证据判断：
- 查
v$dataguard_stats的transport lag：开启后若明显下降（比如从 5 秒降到 0.8 秒），且网络流量监控（如netstat -i或交换机端口计数）同步减少 20%~40%，大概率生效 - 对比
v$archived_log的blocks * block_size总量与网络实际传输字节数（粗略估算，误差 ±30% 是常态） - 查
ADRCI日志里有没有类似Redo transport compression enabled for destination的提示（非必现，但出现即强信号） - 最硬核：抓包看 TCP payload 是否变小（需停业务配合，生产慎用）
最容易被忽略的是——压缩收益高度依赖日志内容可压缩性。如果主库大量写入的是加密字段、随机二进制或已压缩 BLOB，压缩率可能趋近于 0，CPU 白花了。
