compression=enable仅对oracle net网络传输阶段生效，不压缩磁盘上已生成的.arc文件；需12cr2+版本、显式配置valid_for和net_timeout，且依赖lgwr/lns路径，oltp场景压缩率约2:1～3:1，但高cpu开销或不可压缩日志可能适得其反。
COMPRESSION=ENABLE只对网络传输生效，不压缩磁盘.arc文件
归档日志压缩不是“把已生成的.arc文件再压一遍”，而是主库在通过 Oracle Net 向备库发送日志流时，实时压缩网络载荷。这意味着：COMPRESSION=ENABLE 对 /archivelog/2026_07_20/1_12345.arc 这类已落盘的文件毫无影响，也不会触发重写或后台压缩任务。
- 必须走 Oracle Net 协议（即
SERVICE=xxx配置），NFS 挂载、LOCATION=/shared/arch等本地路径方式完全绕过压缩逻辑 - 仅限 12cR2 及以上版本；11g 中该参数存在但仅在归档间隙修复（gap recovery）时启用，且需 Advanced Compression License 授权
- 压缩由主库
ARCH进程（或LGWR，取决于传输模式）CPU 实时完成，高并发下可能抬升 CPU 使用率 20%～40%
必须显式配置LOG_ARCHIVE_DEST_n，且带VALID_FOR和NET_TIMEOUT
光写 COMPRESSION=ENABLE 不够，常见失效原因是参数残缺或路径 fallback 到非压缩通道。典型错误配置：LOG_ARCHIVE_DEST_2='SERVICE=standby_db' —— 缺少 VALID_FOR，系统可能降级为 ARCH 进程归档直传，压缩失效。
- 正确写法示例：
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必须明确指定(ONLINE_LOGFILES,PRIMARY_ROLE)，否则 Data Guard 可能选择 ARCH 路径而非 LGWR/LNS 传输路径 -
NET_TIMEOUT建议设为 120～180 秒；太小（如默认 30）会导致压缩过程超时后断连重试，反而加剧 lag
压缩率不可控，OLTP 场景约 2:1，批量写入可能跌破 1.2:1
Oracle 内部用的是轻量级 LZ4 变种算法，压缩效果完全取决于日志内容特征，不是靠调参数能改变的。你无法通过 SQL 查到某次传输的具体压缩比，v$archived_log.bytes 是解压后文件大小，不能直接和网络流量对比。
- OLTP 短事务 + 大量空块 → 实测压缩率常达 2:1～3:1（100MB 日志传过去约 35–50MB）
- 全量 INSERT / UPDATE BLOB / 加密表空间日志 → 压缩率可能仅 1.1:1，甚至因 CPU 开销导致
transport lag反升 - 验证是否真生效：查
v$archive_dest_status中TRANSMIT_MODE是否为LGWR，且STATUS为VALID；再看交换机端口流量是否明显下降（非v$dataguard_stats）
别指望压缩解决根本瓶颈，先查清卡在哪一层
开了压缩但 transport lag 没变？大概率问题不在网络带宽。真正拖慢 Data Guard 吞吐的，往往是归档 I/O 或备库应用卡点。
- 主库
ARCH进程写归档到慢盘（NFS、低 IOPS 本地盘）→ 导致归档积压，LGWR 被阻塞，压缩再快也白搭 - 备库
MRP0进程停滞（查v$managed_standby中PROCESS='MRP0'的STATUS和SEQUENCE#）→ 说明是 apply lag，开压缩毫无意义 - 主库
LOG_ARCHIVE_MAX_PROCESSES默认为 4，而实际日志切换频繁时需设为 8+，否则 ARCH 进程排队写归档
压缩只是窄带宽场景下的辅助手段，它不修复 I/O 瓶颈，也不加速日志应用。真正要调的，是归档路径性能、备库并行度、以及传输路径是否稳定——这些比压缩开关本身重要得多。
