ADG未启用表现为OPEN_MODE为READ ONLY而非READ ONLY WITH APPLY，根本原因是日志应用中断：MRP0进程缺失或状态异常（如WAIT_FOR_LOG）、SRL缺失、compatible参数低于11.1.0.0.0、归档传输失败或备库未处于MOUNT状态。
备库OPEN_MODE不是READ ONLY WITH APPLY怎么办
这说明ADG根本没跑起来，不是权限或SQL报错的问题，而是日志应用进程压根没动。最直接的证据就是v$database里OPEN_MODE显示READ ONLY，而不是READ ONLY WITH APPLY。
先查状态：SELECT OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE FROM v$database;
再盯MRP0进程：SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM v$managed_standby WHERE PROCESS = 'MRP0';
如果没结果、或者STATUS是WAIT_FOR_LOG或WAIT_FOR_GAP，基本就是卡在启动环节。
- 确保备库处于
MOUNT状态——OPEN READ ONLY后不能直接启实时应用，必须SHUTDOWN IMMEDIATE再STARTUP MOUNT - 检查
compatible参数：低于11.1.0.0.0会静默禁用ADG，用SHOW PARAMETER compatible确认，不达标就得停库改SPFILE再重启 - 确认有可用的
STANDBY REDO LOGS（SRL）：大小和组数至少等于主库ONLINE REDO LOGS，缺SRL会导致USING CURRENT LOGFILE命令挂起或报错
MRP0进程缺失或状态异常怎么恢复
MRP0不出现，常见原因是归档传输没通、日志堆积未触发、或参数standby_file_management没设为AUTO。别急着手动RECOVER，先看底层是否就绪。
运行：SELECT DEST_ID, STATUS, ERROR FROM v$archive_dest WHERE DEST_ID = 2;
如果STATUS不是VALID，或ERROR列有ORA-16057、ORA-12514之类，说明归档根本没传过来，日志应用自然无从谈起。
- 检查主库
LOG_ARCHIVE_DEST_2中SERVICE值是否严格等于备库的DB_UNIQUE_NAME（不是INSTANCE_NAME，也不是TNS别名里的SERVICE_NAME） - 备库监听器必须静态注册，
listener.ora里要有(GLOBAL_DBNAME = <db_unique_name>)</db_unique_name>，且lsnrctl status输出中该服务状态为READY -
standby_file_management必须为AUTO，否则文件名转换失败会导致MRP0启动即退出
启动实时应用时提示ORA-16191或卡在WAIT_FOR_GAP
ORA-16191本质是日志应用中断，不是配置错误，而是数据层面出了问题：块损坏、表空间不一致、或归档日志本身缺失。WAIT_FOR_GAP则明确告诉你有断档，但MRP0找不到那些日志文件。
先定位缺口：SELECT * FROM v$archive_gap;
如果返回结果，说明主库确实没把LOW_SEQUENCE#到HIGH_SEQUENCE#之间的归档发过来，或者发了但备库没收到/没注册。
- 去主库归档目录手动找对应序列号的归档日志，存在就scp过去，再在备库用
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<path>'</path>注册 - 如果控制文件
control_file_record_keep_time设得太小（比如7天），而断档超过这个时间，旧日志元数据已被清理，只能重建备库或从备份恢复 - ORA-16191伴随
ORA-00308或ORA-16055，大概率是归档路径写满、权限不对，或ASM diskgroup未挂载——别只看alert.log，也得df -h和ls -ld一起查
Broker启用后MRP0仍不启动的隐藏坑
DG Broker开了不代表日志应用自动接管。Broker只管配置同步和角色切换，MRP0是否启动、用不用CURRENT LOGFILE，还是得靠传统SQL命令控制。很多人配完Broker就以为万事大吉，结果show configuration一切正常，但备库始终READ ONLY。
Broker模式下，RECOVER MANAGED STANDBY DATABASE命令依然有效，且优先级高于Broker内部调度。如果之前用Broker启过ENABLE CONFIGURATION，但没显式执行启动命令，MRP0就不会自己冒出来。
- Broker配置里
LogXptMode设为SYNC或ASYNC，只影响传输方式，不等于开启应用；必须单独执行RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - RAC环境要注意：所有实例的
dg_broker_start都得是TRUE且SCOPE为BOTH，否则Broker进程dmon可能只在部分节点运行，导致状态不同步 - Broker日志
$ORACLE_HOME/rdbms/log/drc<db_unique_name>.trc</db_unique_name>里常有线索，比如ORA-16501这种泛型错误，不翻它很难定位真实原因
实际操作中最容易被忽略的是：MRP0是否启动与Broker是否启用是两件事，哪怕Broker配置全绿，也得手动发一次recover命令；而一旦发过，后续重启数据库时，MRP0不会自动续上——必须在startup mount后立刻再执行一遍recover语句。
