有用，但仅在log_archive_dest_n显式配置compression=enable、使用oracle net传输（service=xxx）、主备库均为12cr2+且配net_timeout的条件下生效；压缩发生在主库cpu实时编码阶段，对新归档有效，oltp场景压缩比约2:1～3:1。
LOG_ARCHIVE_DEST_n中COMPRESSION=ENABLE到底有没有用
有用，但只在特定条件下生效：必须是LOG_ARCHIVE_DEST_n配置里显式写了COMPRESSION=ENABLE，且传输走的是Oracle Net（即SERVICE=xxx形式，不是LOCATION=/path本地路径），否则完全不压缩。
常见误操作：
- 只改了LOG_ARCHIVE_DEST_STATE_n没配COMPRESSION
- 漏设NET_TIMEOUT，导致压缩启用后连接频繁中断
- 用NFS挂载或RMAN备份归档，此时压缩参数被忽略
- 主备库版本低于12cR2（11g及更早不支持该参数）
压缩发生在主库CPU实时编码阶段，不是磁盘文件重写。已生成的.arc文件不会变小，新生成的归档才走LZ4变种压缩。OLTP场景下实测压缩比约2:1～3:1，但全量更新或大BLOB插入时可能低于1.2:1，甚至因CPU开销拖慢整体传输。
SDU和Socket Buffer调多大才合适
Oracle Net的SDU（Session Data Unit）和TCP缓冲区大小直接影响单次网络包承载量，对日志流吞吐影响显著。默认SDU是8KB，万兆内网建议直接拉到32767；SEND_BUF_SIZE/RECV_BUF_SIZE建议设为9375000（约9MB）。
必须三处同时生效：
- sqlnet.ora里加DEFAULT_SDU_SIZE=32767
- tnsnames.ora对应备库条目里嵌套(SDU=32767)和(SEND_BUF_SIZE=9375000)
- listener.ora监听器地址段也得加(SEND_BUF_SIZE=9375000)(RECV_BUF_SIZE=9375000)
改完要重启监听器和数据库连接会话，否则不生效。注意：过大的SDU在高丢包率网络下反而增加重传概率，公网环境慎用最大值。
LGWR vs ARCH传输模式怎么选
关键看业务对RPO（恢复点目标）的容忍度，而不是单纯比“快”。
LGWR SYNC模式下，主库事务提交前必须等备库RFS写完SRL并确认，RPO≈0，但延迟敏感型业务（如高频交易）可能卡住；ARCH ASYNC靠归档触发传输，主库无感知，但RPO可能达数分钟——尤其当归档积压时。
真正影响吞吐的常是背后细节：
- LGWR传输要求备库必须配置足够数量的standby redo log组（至少比在线日志多1组）
- ARCH传输受LOG_ARCHIVE_MAX_PROCESSES限制，默认4个不够用，高并发日志需调到8或12
- 无论哪种模式，REOPEN=60必须配，否则单次网络抖动就让归档停滞
比调参更关键的瓶颈在哪
多数人盯着网络和压缩，但实际卡点往往在IO和进程调度。
归档性能70%问题出在存储IO：
- 归档路径不能和数据文件、在线日志共用同一ASM磁盘组或物理盘
- ASM归档专用磁盘组AU_SIZE建议设为4M，避免小AU导致元数据争用
- 机械硬盘归档写入速度普遍低于30MB/s，SSD/NVMe可到300MB/s+，差距十倍
另一个隐形杀手是log file switch (archiving needed)等待事件——这说明LGWR在等ARCn写完归档才能切日志。此时开再大SDU也没用，得先查V$ARCHIVE_DEST里STATUS是否VALID、ERROR列是否为空，再看V$ARCHIVED_LOG里归档生成速率和备库接收速率是否匹配。
