COMPRESSION=ENABLE仅在主库通过Oracle Net向备库实时传输日志时压缩网络载荷，对磁盘上已生成的.arc文件无效；需同时满足12.2+版本、SERVICE协议、LGWR/LNS传输三条件，且参数配置须含NET_TIMEOUT、VALID_FOR、REOPEN等子句。
COMPRESSION=ENABLE 能减带宽，但只在主库通过 Oracle Net 向备库发送日志流时实时压缩网络载荷，对磁盘上已生成的 .arc 文件完全无效。
确认版本与传输路径是否满足前提
19c 支持 COMPRESSION=ENABLE，但必须同时满足三个硬性条件，缺一不可：
- 主备库都运行 Oracle 12.2（12cR2）或更高版本（19c 符合）
- 归档目标必须走 Oracle Net 协议，即配置中含
SERVICE=xxx，不能是LOCATION=/path或 NFS 挂载 - 传输模式必须为
SYNC或ASYNC，且由 LGWR/LNS 进程发起（不是 ARCH 进程直传）
常见失效场景：用 RMAN 备份归档、tnsnames.ora 里配了 SERVICE 但 LOG_ARCHIVE_DEST_n 实际写成了本地路径、或主库未启用 FORCE LOGGING 导致 fallback 到 ARCH 归档。
正确配置 LOG_ARCHIVE_DEST_n 参数
光写 COMPRESSION=ENABLE 不够，漏掉任一关键子句都会导致压缩静默失效。典型正确写法：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC COMPRESSION=ENABLE NET_TIMEOUT=180 VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db REOPEN=60';
必须包含的子句说明：
-
NET_TIMEOUT=180：默认 30 秒太短，压缩过程可能超时断连；设为 120–180 更稳 -
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)：强制走 LGWR/LNS 路径；若省略，Data Guard 可能选 ARCH 路径绕过压缩 -
REOPEN=60：避免单次网络抖动就卡死归档，60 秒后自动重试 -
DB_UNIQUE_NAME必须与备库实际值一致，大小写敏感
改完需执行 ALTER SYSTEM SWITCH LOGFILE 触发新归档，参数才真正生效（不用重启实例，但建议写入 SPFILE 持久化）。
压缩效果与性能权衡要点
压缩率不可控，且开销真实存在：
- OLTP 场景实测约 2:1～3:1（100MB 日志网络传输约 35–50MB），但全量更新、大 BLOB 或 TDE 加密表空间日志基本不压，甚至压缩后更大
- 压缩由主库 CPU 实时完成，ARCH 或 LGWR 进程 CPU 使用率可能抬升 20%～40%，高并发下反而拖慢整体吞吐
-
V$ARCHIVED_LOG.bytes记录的是解压后大小，无法反推压缩比；V$DATAGUARD_STATS也不提供压缩前后字节数字段 - 若网络带宽充裕（如万兆内网）而 CPU 紧张，关压缩 + 调大
LOG_ARCHIVE_MAX_PROCESSES往往比硬开压缩更有效
验证压缩是否真在工作
别只看参数有没有配，重点查运行态：
- 查
V$ARCHIVE_DEST_STATUS中对应DEST_ID的STATUS是否为VALID，ERROR列为空 - 查
V$DATAGUARD_STATS中transport lag和apply lag是否持续增长——若 lag 上升，压缩可能因 CPU 或网络问题被降级 - 备库上查
V$ARCHIVED_LOG.compression，值为ENABLED表示接收端确认收到压缩流（注意：文件大小仍和主库原始.arc一样大） - 最直接方式：在交换机或主机网卡层抓包或看流量计数，对比开启前后单位时间归档数据量变化（误差 ±30% 属正常）
最容易被忽略的一点：压缩只对新生成的归档生效，已落盘的 .arc 文件不会被重写，也不会触发后台压缩任务——所有“减小本地存储”的预期，从一开始就是错的。
