Oracle 19c物理备库实现“实时查询”需满足：处于READ ONLY WITH APPLY状态、MRP0进程STATUS为APPLYING_LOG且SEQUENCE#/BLOCK#持续推进，并执行USING CURRENT LOGFILE命令启用实时应用；权限需在备库显式授予对象级SELECT，DML重定向需开启ADG_REDIRECT_DML参数。
Oracle 19c 物理备库默认就是“实时查询就绪”的——只要它处于 READ ONLY WITH APPLY 状态，无需额外开启任何开关，SELECT 就能立即查到主库刚提交的数据。所谓“开启实时查询功能”，本质是确保备库真正运行在实时应用（Real-Time Apply）模式下，而不是卡在归档日志应用阶段。
确认备库是否真正在实时应用
很多人误以为备库 OPEN_MODE 是 READ ONLY 就够了，其实关键要看日志是否“边收边用”。必须检查 v$managed_standby 中的 MRP0 进程状态：
-
STATUS = 'APPLYING_LOG'且PROCESS = 'MRP0'是基本前提 - 更关键的是
SEQUENCE#是否持续递增、BLOCK#是否在推进；如果长期不动，说明没走实时路径 - 执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;才是启用实时应用的正确命令；用NODELAY而不带USING CURRENT LOGFILE的话，MRP0 只会等归档落盘，必然延迟
为什么 SELECT ANY TABLE 在备库查不到数据
这不是查询功能没开，而是权限模型被只读模式硬性约束。备库禁止任何隐式字典访问，而 SELECT ANY TABLE 的校验过程会去读 obj$、tab$ 等底层字典表，直接触发 ORA-01031 错误。
- 即使你在主库执行了
GRANT SELECT ANY TABLE TO app_user，这条授权也不会在备库生效 - 必须在备库实例（或目标 PDB）中显式执行对象级授权，例如：
GRANT SELECT ON SCOTT.EMP TO app_user - 若需覆盖整个 schema，建议在备库执行动态脚本生成授权语句：
SELECT 'GRANT SELECT ON ' || owner || '.' || table_name || ' TO app_user;' FROM dba_tables WHERE owner = 'SCOTT';
ADG DML 重定向不是“查询功能”，但会影响读一致性体验
如果你在备库上执行了 INSERT/UPDATE/DELETE，又希望后续 SELECT 立即看到结果，就必须启用 DML 重定向（ADG_REDIRECT_DML）。否则 DML 会直接报错 ORA-16000（数据库以只读方式打开）。
- 该功能依赖一个名为
ADGREDIRECT的 public database link，且必须由主库创建（通过 redo 同步到备库） - 备库侧只需执行：
ALTER SYSTEM SET ADG_REDIRECT_DML = TRUE SCOPE=BOTH;，无需重启 - 注意：重定向后的 DML 实际在主库执行，所以备库上的 SELECT 能立刻看到结果，前提是主库已提交、redo 已传回并应用——这再次反向验证了实时应用是否真正跑通
最容易被忽略的一点：备库上新增的数据文件、PDB 或表空间，如果主库有而备库 ASM 中缺失对应磁盘组路径（比如 +DATADG1），MRP0 会静默挂起，既不报错也不推进 SEQUENCE#，导致你以为“实时查询”失效，其实只是同步卡死在底层。查 alert.log 比查 SQL 更快定位这类问题。
