ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT NODELAY 不启用实时应用，因其仅启动介质恢复（Media Recovery），未指定 USING CURRENT LOGFILE，故MRP0处于 WAIT_FOR_LOG 或 NOT ACTIVE 状态；真正启用实时应用的命令是 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT。
为什么alter database recover managed standby database disconnect nodelay不启用实时应用
执行这条命令后，mrp0进程启动但status显示wait_for_log或not active，说明根本没走实时路径。关键原因在于：它只启用介质恢复（media recovery），不自动开启实时应用（real time apply）——后者需要额外触发条件。真实生效的命令是：alter database recover managed standby database using current logfile disconnect。漏掉using current logfile，就等于告诉oracle“等归档落盘后再开始”，自然无法实时。
LOG_ARCHIVE_DEST_2配置中ASYNC和AFFIRM参数如何影响同步行为
主库LOG_ARCHIVE_DEST_2若设为LGWR ASYNC但没配AFFIRM=NO，LNS进程会等待备库写入磁盘确认，网络抖动时直接BLOCK#卡死；而设成ARCH ASYNC则依赖主库本地归档完成才发，ARCH进程一旦卡在WAIT_FOR_LOG，归档传输就彻底停摆。必须检查：show parameter log_archive_dest_2输出中是否含VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，缺这个会导致RAC主库切换角色后传输失效。
v$managed_standby里MRP0状态正常但sequence#不变怎么办
MRP0存在且status为APPLYING_LOG，但sequence#长期不动，八成是卡在某个归档日志的应用环节。优先查备库alert.log，搜ORA-01111（UNNAMED文件）、ORA-01193（数据文件不一致）、corruption或undo。特别注意新增数据文件或PDB后未同步的情况：主库多出的+DATADG1路径，备库ASM里根本不存在，MRP0会静默挂起，不报错也不推进。
备库v$archive_gap为空却不同步，该查什么
v$archive_gap返回空，只代表归档日志全部收到了，不代表已应用。此时必须交叉验证：
• 查v$logstdby（逻辑DG）或v$managed_standby（物理DG）确认MRP0是否真在跑
• 查v$dataguard_stats里的apply lag和transport lag值，>0即存在延迟
• 检查standby_file_management是否为AUTO，若为MANUAL且新增数据文件未手动创建，MRP0遇到UNNAMED文件会停住
• 确认主库db_unique_name和备库LOG_ARCHIVE_DEST_2中配置的DB_UNIQUE_NAME完全一致，大小写敏感
LOG_ARCHIVE_DEST_2写了LGWR ASYNC，但忘了加AFFIRM=NO；或者standby_file_management=AUTO，却没配好db_file_name_convert导致新PDB数据文件路径解析失败。这些细节不逐项核对，光重启MRP只会反复踩进同一个坑。 
