备库开启ADG前必须设STANDBY_FILE_MANAGEMENT=MANUAL，否则OPEN READ ONLY报ORA-16004；ORA-10458主因是MRP未运行，需确保RECOVER后MRP0状态为APPLYING_LOG；正常ADG下V$DATABASE.OPEN_MODE应为READ ONLY WITH APPLY。
备库开启实时查询（ADG）前必须关闭 STANDBY_FILE_MANAGEMENT
不关这个参数，后续 alter database open read only 会报 ora-16004: backup database requires recovery 或卡在 mrp 进程无法启动。它默认是 auto，但 adg 模式下主库新增数据文件时，备库若自动创建同名文件，可能因路径不存在或权限不足直接中断恢复。
-
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SCOPE=BOTH;—— 必须在备库MOUNT状态下执行 - 如果主库已新增过数据文件，需手动在备库创建对应文件（路径、大小一致），再用
RECOVER MANAGED STANDBY DATABASE续上日志 - 切忌在
READ ONLY状态下改这个参数，会报ORA-02095
ALTER DATABASE OPEN READ ONLY 报 ORA-10458 的真实原因
这个错误不是“不能开”，而是当前备库还没追平主库归档或在线日志——MRP 进程没运行或已停止。ADG 要求物理备库先完成介质恢复（RECOVER），再应用实时日志流，最后才能只读打开。
- 查状态：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY;—— 确保有MRP0且STATUS = APPLYING_LOG - 若无 MRP 进程，执行：
RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; - 如果主库切换了日志但备库没收到，检查
LOG_ARCHIVE_DEST_n的VALID_FOR和网络连通性，特别注意ASYNC模式下可能丢日志
启用实时查询（ACTIVE DATA GUARD）后，V$DATABASE.OPEN_MODE 显示 READ ONLY WITH APPLY
这是唯一能确认 ADG 正常工作的标志。仅显示 READ ONLY 说明 MRP 停了，实际是静态备库；显示 MOUNTED 则根本没开。
- 检查语句：
SELECT OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE;—— 三者必须是READ ONLY WITH APPLY/PHYSICAL STANDBY/MAXIMUM PERFORMANCE（或其他允许异步的模式） - 如果开了但查询卡顿，大概率是
_disable_fast_instance_recovery=TRUE被误设（常见于旧版补丁），会导致日志应用延迟升高 - 应用日志的 I/O 压力集中在备库 redo apply 进程，别跟主库共用同一套存储 LUN，否则延迟飙升
只读打开后，SELECT 查询仍被阻塞？盯紧 enq: KO - fast object checkpoint
这是 ADG 最隐蔽的性能坑：当主库频繁做 DML + 备库并发查询高时，Oracle 会在备库后台触发对象级检查点，阻塞查询等待。现象是 v$session_event 里该事件排前三，且 SQL_ID 对应的语句长时间 WAITING。
- 临时缓解：
ALTER SYSTEM SET "_disable_fast_instance_recovery"=TRUE SCOPE=MEMORY;（重启失效，慎用于生产） - 长期方案：调大备库
DB_CACHE_SIZE，减少 checkpoint 频率；或限制主库批量操作频率，避免短时间内大量脏块刷出 - 不要依赖
FLASHBACK QUERY在 ADG 上做一致性读——它会加剧 KO 等待，真要闪回，用主库的AS OF TIMESTAMP
ADG 的“实时”是相对的，延迟取决于网络、I/O、主库负载和参数组合。最容易被忽略的是：STANDBY_FILE_MANAGEMENT 的切换时机、OPEN READ ONLY 前 MRP 的存活确认、以及 KO 等待这种不报错却卡查询的软故障。
