ADG实时查询生效需主备DB_NAME一致且STANDBY_FILE_MANAGEMENT=AUTO；正确启动流程为STARTUP MOUNT后执行ALTER DATABASE RECOVER...USING CURRENT LOGFILE；并配置UNDO表空间RETENTION GUARANTEE及足够UNDO_RETENTION。
ADG实时查询没生效？检查STANDBY_FILE_MANAGEMENT和DB_NAME是否一致
adg实时查询（active data guard）不是开个参数就自动可用的，最常被忽略的是主备库的db_name必须完全相同，且standby_file_management必须设为auto。否则即使打开了open_mode为read only with apply，查询也会报ora-16000: database open for read-only access或直接卡在应用日志阶段。
-
DB_NAME不一致会导致备库无法正确识别主库的SCN推进，从而拒绝启用实时查询 -
STANDBY_FILE_MANAGEMENT=MANUAL时，新增数据文件不会自动创建，后续SELECT碰到未同步的段会报ORA-01157 - 验证命令：
SHOW PARAMETER DB_NAME、SHOW PARAMETER STANDBY_FILE_MANAGEMENT
如何确认ADG已真正进入实时查询状态
光看SELECT OPEN_MODE FROM V$DATABASE返回READ ONLY WITH APPLY还不够——这只是“正在应用”，不等于“可查最新”。关键要看V$DATAGUARD_STATS里的apply lag是否稳定在秒级（比如0 days 00:00:02），以及V$ARCHIVE_DEST_STATUS中目标备库的STATUS是VALID、RECOVERY_MODE是MANAGED REAL TIME APPLY。
- 如果
RECOVERY_MODE显示MANAGED STANDBY，说明还没启用实时应用，需检查ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT是否执行成功 - 用
SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY比对主备归档序号差，超过3个就说明延迟过大，实时查询结果可能滞后 - 简单验证：主库插入一行+
COMMIT，立刻在备库查同一行——若能秒级查到，才算真正就绪
ALTER DATABASE OPEN READ ONLY之后不能直接启实时查询？顺序错了
ADG不是先OPEN READ ONLY再“开启”实时查询，而是必须用特定命令组合触发实时应用模式。手动执行ALTER DATABASE OPEN READ ONLY只会进普通只读态，V$DATABASE.OPEN_MODE变成READ ONLY，此时RECOVERY_MODE为空，APPLY LAG也不会更新。
- 正确流程只有这一种：
STARTUP MOUNT→ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 执行后
V$DATABASE.OPEN_MODE自动变为READ ONLY WITH APPLY，无需额外OPEN命令 - 如果误执行了
ALTER DATABASE OPEN READ ONLY，必须先SHUTDOWN IMMEDIATE，再STARTUP MOUNT重走上面流程，不能用ALTER DATABASE RECOVER...强行追加
备库查询变慢或报ORA-0155？检查UNDO_RETENTION和GUARANTEE
ADG实时查询依赖备库本地UNDO维持一致性读，但默认UNDO表空间不会自动RETENTION GUARANTEE。一旦主库产生大量事务，备库UNDO可能被覆盖，导致长查询报ORA-0155: snapshot too old，或者明显卡顿。
- 必须在备库执行：
ALTER TABLESPACE UNDOTBS1 RETENTION GUARANTEE（替换UNDOTBS1为实际UNDO表空间名） - 同时调大
UNDO_RETENTION（建议≥1800秒），并确保UNDO表空间足够大，避免自动扩展失败 - 注意：
RETENTION GUARANTEE不可逆，除非显式执行NORETENTION，否则重启后依然生效
