必须启用lgwr+sync/async且备库配置srl，否则real-time apply无法启动；常见因主库未配lgwr、备库缺srl、valid_for参数错误等导致mrp0未启动。
必须启用 LGWR + SYNC/ASYNC 模式，且备库需有 Standby Redo Log（SRL），否则 real-time apply 无法启动。
为什么 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 不生效
常见错误是执行该命令后日志应用仍卡在归档日志阶段，v$managed_standby 中 PROCESS 显示为 ARCH 而非 MRP0，说明未进入实时应用模式。
- 根本原因：主库未配置
LGWR传输，仍走默认的ARCH进程——后者只传归档日志，无法实时推送在线日志 - 备库缺少 Standby Redo Log（SRL）：即使主库用 LGWR，备库没有 SRL 就无法接收在线日志流，RFS 进程会直接报错
ORA-16038: log 4 sequence# 123 cannot be archived - 参数
LOG_ARCHIVE_DEST_2中未指定VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，导致该路径仅对归档日志生效
添加 Standby Redo Log 的实操要点
SRL 不是“可选”，而是实时应用的强制依赖。大小、组数、路径需与主库 Online Redo Log 严格一致，且主备库都要建。
- 先查主库 Online Redo Log：运行
SELECT GROUP#, BYTES FROM v$log，确认每组大小（如 50M）和组数（如 3 组） - 按“主库组数 + 1”原则建 SRL：至少比 Online Redo Log 多一组，例如主库有 3 组 Online，则备库建 4 组 SRL；命令形如
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/path/std_redo04.log' SIZE 50M - 路径建议与 Online Redo Log 同目录，避免因权限或空间问题导致 RFS 写失败；若路径不同，需确保
STANDBY_FILE_MANAGEMENT=AUTO已启用 - 建完后在备库查
v$standby_log，状态应为UNASSIGNED或ACTIVE，而非UNUSED
主库 LOG_ARCHIVE_DEST_n 参数的关键配置
仅靠 USING CURRENT LOGFILE 命令不够，底层传输通道必须正确指向备库并启用实时机制。
-
LOG_ARCHIVE_DEST_2必须含SERVICE=tns_alias LGWR SYNC/ASYNC，其中tns_alias是备库的 TNS 名称，需在tnsnames.ora中正确定义 -
VALID_FOR必须为(ONLINE_LOGFILES,PRIMARY_ROLE)：前者确保传输在线日志，后者限定仅主库角色启用该路径 -
DB_UNIQUE_NAME必须与备库实际值一致，且主备库LOG_ARCHIVE_CONFIG需统一设为DG_CONFIG=(primary_db,standby_db) - 禁用
ARCH传输干扰：确保LOG_ARCHIVE_DEST_STATE_2=ENABLE，同时其他远程路径（如DEST_3）不要重复指向同一备库
启动实时应用后的验证与典型陷阱
启动后不能只看命令是否返回成功，要验证 MRP 进程是否真正接管日志流。
- 在备库执行
SELECT PROCESS, STATUS, SEQUENCE# FROM v$managed_standby，关键指标是出现MRP0进程且STATUS为APPLYING_LOG - 检查
v$dataguard_stats中apply_lag和transport_lag，理想值应 ≤ 10 秒；若持续 > 60 秒，大概率是网络延迟或 SRL 空间不足 - 常见静默失败：备库
archive_lag_target参数设得太小（如 0），会强制切归档，反而绕过实时路径；建议保持默认或设为 0 以外的值 - 切换后角色反转：主库变备库时，原
LOG_ARCHIVE_DEST_2配置自动失效，必须用 Data Guard Broker 或手动重配新主库的DEST_2，否则新主库无法向新备库传日志
最容易被忽略的是 Standby Redo Log 的组数和大小匹配——差 1 字节或少建 1 组，MRP 就永远停在“等待下一个日志”状态，而错误日志里往往只报模糊的 I/O 超时。
