应使用COMPRESSION=ENABLE而非_REDO_TRANSPORT_COMPRESS，因后者是19c默认关闭的隐含参数，仅对LGWR DIRECT有效且需重启；而前者是显式参数，支持所有Oracle Net传输、无需重启、可验证生效。
能配，但必须用 COMPRESSION=ENABLE，不是设隐含参数 _REDO_TRANSPORT_COMPRESS——后者在 19c 里默认关、不推荐、且只对 LGWR DIRECT 模式有效。
为什么不用 _REDO_TRANSPORT_COMPRESS 而用 COMPRESSION=ENABLE
Oracle 19c 支持两种日志压缩机制，但适用场景和可控性差别很大：
-
_REDO_TRANSPORT_COMPRESS是隐含参数，19c 中默认关闭，需SCOPE=SPFILE+ 重启，且仅对LGWR SYNC/DIRECT传输路径生效；ARCH或ASYNC模式下完全不触发 -
COMPRESSION=ENABLE是显式归档目的地参数，12.2+ 就支持，19c 已稳定，作用于所有 Oracle Net 传输（包括LGWR ASYNC），无需重启，改完立即对新生成的归档生效 - 隐含参数无状态反馈，无法从
v$archive_dest_status或告警日志确认是否真在压缩；而COMPRESSION=ENABLE启用后，备库v$archived_log.compression列会显示ENABLED，可验证
LOG_ARCHIVE_DEST_n 中启用压缩的实操要点
压缩不是加个参数就自动生效，必须满足几个硬性条件：
- 主库必须运行 Oracle 12.2 或更高版本（19c 满足）；备库版本不能低于主库
- 传输必须走 Oracle Net（即
SERVICE=xxx），不能是LOCATION=本地路径或 NFS 挂载 -
VALID_FOR必须明确指定，例如VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)；写成(ALL_LOGFILES,PRIMARY_ROLE)可能导致 Broker 跳过该路径 - 必须配
NET_TIMEOUT=180（建议值），否则压缩过程稍慢就会触发超时重试，反而增加延迟 - 示例完整配置：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db LGWR ASYNC COMPRESSION=ENABLE NET_TIMEOUT=180 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db';
压缩效果与风险：别为省带宽拖垮 CPU
压缩率高度依赖日志内容，不是所有场景都适合开：
- OLTP 类事务（大量小更新、空闲块多）压缩率通常在 2:1～3:1；全量更新、大 BLOB 插入、加密表空间日志几乎不压缩（
- 压缩由主库 ARCH 或 LGWR 进程实时完成，高并发日志生成时可能显著抬升 CPU 使用率，尤其当
LOG_ARCHIVE_MAX_PROCESSES已设较高值时 - 网络带宽充裕（如万兆内网）、CPU 紧张的环境，应优先调低归档进程数或优化 I/O，而非强开压缩
- 压缩不改变日志校验逻辑，但会掩盖底层网络问题：如果丢包率 >0.1%，压缩后重传数据更多，可能加剧 lag 波动
如何确认压缩真的在工作
不能只看参数设了没，要查运行态证据：
- 主库查：
SELECT dest_id, status, error FROM v$archive_dest WHERE dest_id = 2;——STATUS必须为VALID，ERROR为空 - 备库查：
SELECT sequence#, compression FROM v$archived_log WHERE standby_dest = 'YES' AND compression = 'ENABLED' AND rownum <= 5;—— 有结果说明解压成功且标记正确 - 最直接验证法：在主备库分别抓 5 分钟网络流量（如
iftop -P 1521），对比压缩前后字节数；注意排除 RMAN 备份、监听通信等干扰流 - 不要依赖
v$dataguard_stats.transport_lag下降来判断——它受多种因素影响，压缩只是其一
真正卡 Data Guard 吞吐的，往往不是网络带宽，而是主库归档写盘慢、备库 MRP 应用阻塞、或 Standby Redo Log 组数不足。压缩只是辅助手段，不是故障兜底方案。
