adg未真正启用表现为备库open_mode为read only而非read only with apply，主因是日志应用中断：mrp0进程未处于applying_log状态、srl缺失、compatible参数低于11.1.0.0.0、归档传输配置异常或备库未处于mount状态即尝试启动实时恢复。
备库处于 read only 而非 read only with apply，说明 adg 没真正启用，不是查询权限或对象问题，而是日志应用状态卡住了。
检查当前备库打开模式和恢复状态
直接查 v$database 和 v$archive_dest_status 是最快定位手段。如果 OPEN_MODE 是 READ ONLY，且 RECOVERY_MODE 是 MANAGED STANDBY RECOVERY 或空，基本可断定日志没在实时应用。
- 运行
SELECT OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE FROM v$database;—— 正常 ADG 应返回READ ONLY WITH APPLY - 运行
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM v$managed_standby;—— 关注MRP0进程是否为APPLYING_LOG，若为WAIT_FOR_LOG或缺失该进程，说明日志流中断 - 查
v$archive_dest_status中STATUS是否为VALID，ERROR列是否有内容（如ORA-16057、ORA-12514）
确认 compatible 参数是否 ≥ 11.1.0.0.0
这是 Oracle 11g ADG 启动的硬性门槛。哪怕数据库版本是 11.2.0.4，只要 compatible 仍设为 10.2.0.0.0（升级后未手动调整），ADG 就会静默降级为只读备库，ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE 也会失败或无效果。
- 查当前值：
SHOW PARAMETER compatible - 若值低于
11.1.0.0.0，必须停库修改：ALTER SYSTEM SET compatible='11.1.0.0.0' SCOPE=SPFILE;，然后SHUTDOWN IMMEDIATE+STARTUP MOUNT+ALTER DATABASE OPEN - 注意：此操作不可逆，且要求所有数据文件都已由 11g 兼容格式重写（通常升级后执行过
DBMS_STATS或 DML 即可满足）
启动实时日志应用前必须满足的三个前提
缺一不可。常见错误是只关注 SQL 命令而忽略底层依赖。
- 备库必须处于
MOUNT状态才能执行RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE；如果已OPEN READ ONLY，先SHUTDOWN IMMEDIATE再STARTUP MOUNT - 主库归档目标必须配置
SYNC或ASYNC并启用CURRENT LOGFILE传输，例如：LOG_ARCHIVE_DEST_2='SERVICE=standby_db ASYNC VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=standby_db' - 备库必须有可用的
STANDBY REDO LOGS (SRL)，且大小、组数 ≥ 主库ONLINE REDO LOGS。缺少 SRL 会导致USING CURRENT LOGFILE报错或挂起
ORA-01555 在 ADG 查询中频繁出现怎么办
这不是参数调大 UNDO_RETENTION 就能解决的。11g ADG 存在已知 Bug（MOS ID 1273808.1），当开启 USING CURRENT LOGFILE 且查询长时间运行时，UNDO 段可能被覆盖，触发快照过旧。
- 临时缓解：避免长事务查询，加
/*+ NO_PARALLEL */减少并行消耗，控制查询执行时间 - 根本修复：应用补丁
10018789，或升级至11.2.0.2.2及以上版本（Windows 需11.2.0.2.3） - 不建议关闭
USING CURRENT LOGFILE来规避 —— 这等于退回到传统物理备库，失去实时查询意义
最关键的盲点是：很多人以为“开了 ADG”就是一劳永逸，但 compatible 参数一旦卡在 10g 水平，整个机制就形同虚设；而 STANDBY REDO LOGS 的缺失又不会报严重错误，只会让日志应用卡在“等待下一个归档”状态，表面安静，实则失效。
