备库开启后仍不实时同步，八成是LOG_ARCHIVE_DEST_STATE_2被设为DEFER或RESET而非ENABLE；该参数决定日志是否发送，STATUS为VALID且ERROR为空才表示路径就绪，需执行ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE并配合ALTER SYSTEM SWITCH LOGFILE方可生效。
备库开启后仍不实时同步，八成是 log_archive_dest_state_2 被设为 defer 或 reset，而不是 enable——这个参数不生效，主库日志根本不会发出去，备库连日志影子都收不到。
查 LOG_ARCHIVE_DEST_STATE_2 是否真启用
别只看 log_archive_dest_2 配了没，STATE 才决定它动不动。在主库执行：
SELECT DEST_ID, STATUS, ERROR, DESTINATION FROM v$archive_dest WHERE DEST_ID = 2;
关键看 STATUS 字段：VALID 且 ERROR 为空才表示路径就绪；若为 INACTIVE 或 ERROR 非空，说明 LOG_ARCHIVE_DEST_STATE_2 没起作用。
-
LOG_ARCHIVE_DEST_STATE_2必须显式设为ENABLE，默认值不是ENABLE（尤其重启后可能回退） - 执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE;后，需强制一次日志切换：ALTER SYSTEM SWITCH LOGFILE;，否则不会触发传输 - 如果用的是 Broker 管理，
ENABLE状态由DGMGRL控制，直接改参数可能被覆盖——优先用ENABLE DATABASE命令
LOG_ARCHIVE_DEST_STATE_n 和角色切换的隐性冲突
主库切为 standby、或备库切为 primary 后，LOG_ARCHIVE_DEST_STATE_2 可能自动失效——Oracle 会按 VALID_FOR 规则重置状态，不是“配一次就永远有效”。
- 检查当前角色是否匹配
log_archive_dest_2的VALID_FOR：比如配了VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，但主库已 switchover 成 standby，则该 dest 自动 disable - 角色切换后，必须确认
v$archive_dest中对应DEST_ID=2的STATUS是否恢复为VALID；否则要手动ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2 = ENABLE; - 常见误操作：在备库上也配了
log_archive_dest_2指向下游，但没同步更新LOG_ARCHIVE_DEST_STATE_2，导致级联链路静默中断
为什么 ps aux | grep ora_arc 看起来正常，但日志就是不传
ARCH 进程存在 ≠ 在干活。它可能卡在 WAIT_FOR_LOG，或因 LOG_ARCHIVE_DEST_STATE_2 关闭而根本不尝试发送。
- 查
V$ARCHIVE_PROCESSES：若STATE是WAIT_FOR_LOG且长时间不变化，大概率是DEST_STATE为DEFER或网络不通 -
LOG_ARCHIVE_DEST_STATE_2 = DEFER时，ARCH 进程照常运行，但跳过该目标；错误日志里也不会报错，只会安静跳过 - 验证方法：临时把
LOG_ARCHIVE_DEST_STATE_2改成ENABLE，再SWITCH LOGFILE，立刻查v$archived_log看主库是否生成新归档、备库v$managed_standby中 RFS 进程是否有新接收记录
最容易被忽略的是：LOG_ARCHIVE_DEST_STATE_n 是动态参数，但它的生效依赖下一次日志切换；没切日志，就算设成 ENABLE 也等于没开。别只改完就以为万事大吉。
