MRP0状态为APPLYING_LOG但sequence#不动，说明其静默卡在归档日志应用环节；常见原因包括UNNAMED文件、数据文件不一致、ASM路径缺失、standby_file_management非AUTO，或Real-Time Apply底层依赖未满足（如SRL缺失、VALID_FOR配置错误、READ ONLY模式与实时应用互斥）。
MRP0进程状态是APPLYING_LOG但sequence#不动
这说明MRP0看似在运行，实际卡在某个归档日志的应用环节。常见诱因不是网络或传输问题，而是备库本地环境不匹配：
-
v$archive_gap为空，不代表已应用——只代表归档都收到了 - 查
alert.log，重点搜ORA-01111（UNNAMED文件）、ORA-01193（数据文件不一致）、corruption或undo相关错误 - 主库新增了数据文件（尤其用了+DATADG1这类ASM路径），但备库ASM里没对应磁盘组，MRP0会静默挂起，不报错也不推进
-
standby_file_management设为MANUAL时，新增文件必须手动创建；设为AUTO才自动同步，漏配就会卡住
执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE后MRP0仍不实时
Oracle 12c默认启用Real-Time Apply，但前提是底层条件全部满足。漏掉任一环节，命令就“看似生效、实则失效”：
- 备库必须有
standby redo log，且大小、组数与主库online redo log严格一致；否则MRP0无法解析当前日志流 - 主库
LOG_ARCHIVE_DEST_2中必须含VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)，否则RAC主库角色切换后归档传输直接中断 - 若主库用
LGWR ASYNC但未配AFFIRM=NO，LNS进程会等备库磁盘写入确认，网络抖动即BLOCK；换成ARCH ASYNC又依赖本地归档完成，ARCH卡住就全停
备库open_mode是READ ONLY但RECOVERY_MODE显示MANAGED REAL TIME APPLY
这个组合看似正确，实则矛盾——READ ONLY模式下MRP0根本无法写数据文件，Real-Time Apply不可能工作：
- 先确认当前模式：
SELECT open_mode, database_role FROM v$database；正常Real-Time Apply必须是MOUNTED或READ ONLY WITH APPLY - 如果已是
READ ONLY，说明之前执行过ALTER DATABASE OPEN，此时需先CANCEL再重新启动MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL→SHUTDOWN IMMEDIATE→STARTUP MOUNT→ 再执行带USING CURRENT LOGFILE的恢复命令 - 12c中
USING ARCHIVED LOGFILE是显式禁用Real-Time Apply的写法，误用会导致MRP0退回到传统归档应用模式
启用Real-Time Query后MRP0的BLOCK#长期停滞
这不是Real-Time Apply没开，而是开了之后引发的资源争用问题。MRP0和用户查询同时访问Buffer Cache，导致IO恶化：
- 查
v$sysstat中physical reads direct占比是否＞0.3，或db file sequential read平均等待时间是否＞10ms - 查
v$managed_standby：若STATUS为APPLYING_LOG但BLOCK#长时间不动，基本可判定是缓存或IO瓶颈 - 盲目增大
db_cache_size可能触发ORA-04031——必须同步检查shared_pool_size和sga_target是否失衡 - 真实延迟不能只看
v$dataguard_stats里的apply lag，它只是估算值；要用DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER在主备库秒级比对SCN差值
