oracle data guard归档日志压缩仅在log_archive_dest_n配置compression=enable、oracle net传输、主备库12.2+版本下生效，仅压缩网络传输流，不改变磁盘归档文件大小。
能压缩，但只在特定配置下生效：必须用 LOG_ARCHIVE_DEST_n 配 COMPRESSION=ENABLE + Oracle Net 传输（即 SERVICE=xxx），且主备库都得是 12.2+ 版本。
COMPRESSION=ENABLE 只压缩网络流，不碰磁盘上的 .arc 文件
归档压缩不是重写已生成的 .arc 文件，它只在主库通过 Oracle Net 把归档日志发给备库那一瞬间做实时压缩。磁盘上存的原始归档文件大小完全不变，V$ARCHIVED_LOG 里记录的 BLOCKS * BLOCK_SIZE 仍是未压缩尺寸。备库收到后自动解压写入 SRL 或归档目录，所以你查备库的 V$ARCHIVED_LOG，COMPRESSION 列会是 ENABLED，但文件大小和主库原始归档不可直接比。
- 常见误操作：以为开了压缩就能减小本地归档存储 —— 实际毫无影响
- 如果用
RMAN BACKUP ARCHIVELOG或 NFS 挂载方式同步，COMPRESSION=ENABLE完全不触发 - 压缩由主库
ARCH进程 CPU 实时完成，高并发日志下可能抬升 CPU 使用率 15%~30%
必须显式配置 LOG_ARCHIVE_DEST_n，不能只改 STATE 或漏 NET_TIMEOUT
只执行 ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE 不起作用；漏写 NET_TIMEOUT 会导致压缩过程中连接超时、频繁断连重试，甚至降级为明文重传。
- 正确写法示例：
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'; -
VALID_FOR必须指定，否则可能 fallback 到 ARCH 路径（绕过压缩逻辑） -
REOPEN=60建议加上，避免单次网络抖动就卡死归档传输 - 修改后需日志切换才生效，不用重启实例，但参数要写进 SPFILE 才持久
压缩率不稳定，OLTP 场景约 2:1～3:1，大 BLOB 或加密表空间几乎不压
Oracle 用的是 LZ4 变种算法，对连续零值、重复块敏感。实测中：
- 典型 OLTP 日志：压缩率 2:1～3:1（100MB 日志传过去约 35–50MB）
- 全量更新或插入大 BLOB：压缩率可能跌到 1.2:1 以下，甚至因压缩开销反拖慢传输
- 使用透明数据加密（TDE）的表空间：日志基本不可压缩，开压缩纯属白耗 CPU
- 无法监控具体压缩比 ——
V$DATAGUARD_STATS和 ADRCI 日志里没有「压缩前/后字节数」字段，只能靠交换机端口流量计数粗略估算，误差常达 ±30%
_REDO_TRANSPORT_COMPRESS 隐含参数已逐步淘汰，优先用 COMPRESSION=ENABLE
该隐含参数在 12.1–19c 默认关闭，21c 起仅对 DIRECT 模式默认启用，且必须配合 LGWR 传输路径（即 LOG_ARCHIVE_DEST_n 中带 LGWR）。但它不可控、难诊断、重启才生效，而 COMPRESSION=ENABLE 是显式语法，支持在线调整，错误提示也更明确。
- 查当前值：
SHOW PARAMETER _REDO_TRANSPORT_COMPRESS（注意是隐含参数，ALTER SYSTEM SET必须加SCOPE=SPFILE） - 验证是否启用：查
V$ARCHIVE_DEST_STATUS中TRANSMIT_MODE是否为LGWR，且STATUS为VALID；再看V$DATAGUARD_STATS中transport lag是否显著下降 - 真正卡 Data Guard 吞吐的，往往不是带宽，而是主库归档 I/O 瓶颈（比如 ARCH 写慢盘）、备库 MRP 被长事务阻塞、或
LOG_ARCHIVE_MAX_PROCESSES设太低 —— 这些问题开了压缩也白搭
压缩不是银弹。最容易被忽略的是：它只解决“传输中”的带宽压力，对归档积压、备库应用慢、网络丢包率高（>0.1%）等问题毫无帮助，反而可能因压缩失败引发重传风暴。上线前务必在业务低峰做真实日志流压测，别只看理论压缩率。
