备库归档堆积本质是日志“送得慢”或“收得慢”，需先定位卡点：查v$archive_dest_status看ERROR列、v$managed_standby看LNS/RFS/MRP0状态，结合v$dataguard_stats的transport lag与apply lag区分传输或应用瓶颈，再针对性优化网络、参数或并行配置。
备库归档堆积，本质是日志“送得慢”或“收得慢”，不是单纯删归档就能解决的。必须先定位卡点：是主库发不出去？网络堵？还是备库mrp0应用不动？
查清堆积源头：v$archive_dest_status 和 v$managed_standby 是关键
别急着删归档，先看传输链路哪一环断了。
-
v$archive_dest_status中ERROR列非空，说明LOG_ARCHIVE_DEST_2配置失败或网络不通，常见错误如ORA-16057: DGID not set或TNS-12541: no listener -
v$managed_standby里如果LNS进程状态是IDLE但SEQUENCE#不涨，主库根本没在发；如果RFS状态是CONNECTED但MRP0是WAIT_FOR_LOG，说明日志已收到但应用卡住 - 特别注意
v$dataguard_stats的transport lag和apply lag：前者持续增长 → 主库→备库传输慢；后者涨而前者不涨 → 备库应用慢
log_archive_dest_2 配置错一个字母就失效
这个参数写错，备库连归档都收不到，堆积只是表象。
- 错误写法：
LOG_ARCHIVE_DEST_2='LOCATION=/arch'—— 这是本地归档，不是DG传输，LGWR或ARCH进程根本不会往备库推 - 正确写法必须含
SERVICE=xxx，例如：LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC NOREGISTER VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' - 如果用的是
SYNC模式，还要确认备库log_archive_config包含主库的DB_UNIQUE_NAME，否则主库拒绝同步提交 - 修改后必须执行：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;，DEFER状态下再正确的配置也白搭
MRP0 应用慢？优先调并行和缓冲，别硬扛IO
MRP0 单线程解析重做日志，遇到大事务或索引维护容易拖慢。优化重点不在磁盘，而在内存和CPU调度。
- 启用并行应用：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE PARALLEL 4;（数字按CPU核数设，别超8） - 增大日志挖掘缓冲：
EXEC DBMS_LOGMNR.START_LOGMNR(OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + DBMS_LOGMNR.COMMITTED_DATA_ONLY + DBMS_LOGMNR.PRINT_PRETTY_SQL);不直接改参数，而是靠隐含参数_log_parallelism_max控制（需重启） - 检查是否启用了
ENABLE_GOLDENGATE_REPLICATION或ENABLE_DDL_LOGGING，这类元数据会显著膨胀归档体积，非必要建议关闭 - 如果
v$managed_standby显示MRP0长期APPLYING_LOG但 CPU 占用低，大概率是磁盘读取慢——此时应查io_wait而非调Oracle参数
TCP窗口和SACK不开，高延迟链路上日志传输效率直接腰斩
主备跨机房、跨城部署时，系统默认TCP参数会让DG传输变成“一发一等”，吞吐上不去。
- 必须开
net.ipv4.tcp_sack=1：否则单个TCP段丢包，整个1MB+归档块重传，v$dataguard_stats里transport lag会锯齿状飙升 -
tcp_rmem和tcp_wmem第三项（max）至少设为带宽×RTT，例如 100Mbps + 30ms RTT → BDP ≈ 375KB → 设"4096 262144 524288" - Oracle 12c+ 建议关掉
_tcp_fast_open（设为FALSE），某些Linux内核版本下它和DG重传逻辑冲突，导致RFS进程频繁断连 - 验证是否生效：
ss -i查看实际连接的rcv_space和ssthresh，不能只信sysctl输出
归档堆积最易被忽略的点：不是参数没调够，而是没分清 transport lag 和 apply lag 的归属环节。前者动网络和主库配置，后者动备库资源和SQL应用逻辑。混在一起调，越调越乱。
