transport lag 和 apply lag 可能是“假高”：需检查 v$dataguard_stats 中 time_computed、datum_time 与系统时间是否同步；RFS 状态 IDLE 且 transport lag 非零说明传输完成；MRP0 状态 WAIT_FOR_LOG 表示等待联机日志归档；备库 RFS 已收全日志但未应用，因 ADG 默认不实时应用 current logfile，需配置并启用 standby redo log 才支持 real-time apply。
怎么看 transport lag 和 apply lag 到底是不是真延迟
很多 dba 一看到 v$dataguard_stats 里 apply lag 是几小时，就急着去重启 mrp 或切日志，结果发现只是“假高”。关键要看三样东西是否同步：time_computed、datum_time 和当前系统时间。如果 time_computed 是两小时前的值，那 apply lag 再大也没意义——它根本没刷新。
-
transport lag非零，但RFS进程状态是IDLE：说明归档没卡在传输层，主库已发完，备库也收全了 -
apply lag很大，但MRP0状态是WAIT_FOR_LOG：不是没日志，而是它在等“当前联机日志”被归档后才能继续——这就是典型的 not apply current logfile - 查
v$managed_standby时重点盯SEQUENCE#：主库当前sequence#是 14720，备库MRP0卡在 14714，但RFS已收到 14720 → 日志已到，只是没应用
为什么 MRP 不主动应用 current logfile
ADG 默认不会实时拉取并应用主库正在写的联机日志（current online log），除非你明确启用了实时应用（real-time apply）。这个行为不是 bug，是设计使然——它依赖 standby redo log（SRL）是否存在、大小是否匹配、以及是否被正确启用。
- 没配 SRL，或 SRL 组数/大小
- SRL 存在但状态是
UNASSIGNED：检查v$standby_log，常见原因是备库控制文件没识别到 SRL，需执行alter database recover managed standby database using current logfile disconnect - 启用了 real-time apply，但
log_archive_dest_n中漏了SYNC或LGWR：传输模式不支持实时捕获，再怎么配 SRL 也没用
单线程 MRP 应用跟不上怎么办
默认的 MRP 是单进程串行回放，遇到大批量 DML（比如夜间批量导入）、索引重建或大事务，很容易积压。这不是配置错，是能力瓶颈。
- Oracle 12c+ 支持并行恢复：用
alter system set parallel_execution_message_size=8192+ 启动时加parallel_recovery_target=16参数（需重启实例） - 更稳妥的做法是调大
_maximum_parallel_apply_servers（隐含参数，慎用），但优先检查是否有大事务阻塞：查v$logstdby_process和v$logstdby_transaction - 别迷信“越多越好”：并行数超过 CPU 核心数反而引发 latch 争用，建议从 4 起步，观察
DB time和log file sync等待事件变化
最容易被忽略的磁盘与文件陷阱
MRP 报错停摆，alert 日志里找不到明显 ORA- 错误，但 v$recover_file 显示 FILE MISSING 或 UNNAMED00xxx：八成是主库新增了数据文件，备库没跟上。
-
STANDBY_FILE_MANAGEMENT=AUTO时，备库会尝试自动建文件，但若DB_FILE_NAME_CONVERT路径错误，或目标目录磁盘满/权限不足，就会生成UNNAMED占位符，MRP 直接卡死 - 查
v$datafile和v$archived_log的name字段，确认路径是否真实存在；用ls -l看 $ORACLE_HOME/dbs 下的 UNNAMED 文件时间戳，基本就是出问题的那个 SCN 点 - 临时解法：手动在备库创建对应路径 + 文件，再执行
alter database create datafile '/path/to/UNNAMED00xxx' as '/real/path/file01.dbf'，之后 MRP 自动续跑
真正难处理的不是延迟本身，而是延迟背后混杂了传输、应用、文件管理、资源限制四层问题。一次 alter system switch logfile 能让数据“突然同步”，只能说明它原本就卡在日志边界上——而那个边界，往往是你没配 SRL、没开 real-time、或者某张表空间悄悄长出了第 17 个数据文件。
