根本原因是mrp0进程未运行或状态异常、srl缺失/配置不足、compatible参数低于11.1.0.0.0，或备库未在mount状态启动日志应用；必须确保mrp0为applying_log状态、srl组数与大小匹配主库、compatible≥11.1.0.0.0且备库先mount再执行using current logfile。
ADG备库无法实时应用Redo日志，根本原因不是权限或SQL写错，而是日志应用链路在某个环节卡死了——最常见的是MRP0进程没起来、SRL缺失、compatible参数不达标，或者备库根本不在MOUNT状态就强行OPEN。
MRP0进程没处于APPLYING_LOG状态
MRP0（Managed Recovery Process）是备库实时应用Redo的核心后台进程。如果它没运行，或状态是WAIT_FOR_LOG、NOT ACTIVE，那日志就停在归档目录里不动了。
- 查状态用：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM v$managed_standby;—— 必须看到MRP0行且STATUS为APPLYING_LOG - 如果没MRP0，说明
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE根本没执行成功，或执行时备库不在MOUNT状态 - 如果MRP0存在但
STATUS是WAIT_FOR_LOG，大概率是主库没把当前日志推过来，得回头查v$archive_dest_status里的ERROR列（比如ORA-16778或ORA-12514）
STANDBY REDO LOG（SRL）缺失或配置不足
ADG必须靠SRL接收并暂存主库的CURRENT LOGFILE流；没有SRL，USING CURRENT LOGFILE会静默失败或挂起，MRP0也起不来。
- 确认SRL是否存在：
SELECT GROUP#, THREAD#, BYTES, STATUS FROM v$standby_log;—— 至少要有3组，且STATUS不能全是UNASSIGNED - SRL组数和大小必须 ≥ 主库
v$log中ONLINE REDO LOG的组数与单组大小；否则高峰期日志切换快，SRL全ACTIVE就卡住（见ORA-00313类报错） - 常见坑：RAC主库有4个THREAD，但备库只建了1个THREAD的SRL → 缺失THREAD 2~4的日志接收能力
compatible参数低于11.1.0.0.0
这是Oracle 11g ADG的硬性门槛。哪怕数据库版本是11.2.0.4，只要compatible仍为10.2.0.0.0（升级后未手动改），ADG就会自动降级为只读备库，USING CURRENT LOGFILE无效，OPEN_MODE永远是READ ONLY而非READ ONLY WITH APPLY。
- 查当前值：
SHOW PARAMETER compatible - 改法必须停库：
ALTER SYSTEM SET compatible='11.1.0.0.0' SCOPE=SPFILE;→SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE OPEN - 注意：此操作不可逆，且要求所有数据文件已由11g格式重写（通常升级后做过DML或
DBMS_STATS即可满足）
备库没在MOUNT状态就执行OPEN
很多人直接STARTUP备库，结果进的是READ ONLY模式，MRP0压根不会启动——因为日志应用只能在MOUNT状态下发起。
- 正确流程：先
STARTUP MOUNT，再ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;，最后ALTER DATABASE OPEN; - 如果已经
OPEN READ ONLY了，不能直接RECOVER，必须先SHUTDOWN IMMEDIATE，再走上面流程 - 验证是否生效：
SELECT OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE FROM v$database;—— 正常ADG必须返回READ ONLY WITH APPLY
真正难排查的点往往藏在细节里：比如compatible参数看似合规，实则被spfile里另一个隐式参数覆盖；又比如SRL存在但ASM磁盘组没mount（报ORA-15001），导致MRP0一启动就崩溃。别只盯着SQL命令，先看v$database和v$managed_standby这两张表，它们比告警日志更快暴露本质问题。
