ora-16000不是故障，而是物理备库正常只读状态的提示；需确认mrp进程处于applying_log状态、主库启用force logging及archivelog，并使用open read only with apply启动adg。
不能直接在物理ADG备库上配置“只读报表系统”——它本来就是只读的，无需额外配置；但若你遇到查询延迟、ORA-16000报错、或误以为能写入后又失败，说明你混淆了物理ADG和逻辑备库的能力边界。
物理ADG备库默认就是只读报表库，不需要“配置”只读
Oracle 19c Active Data Guard 的物理备库（即标准ADG）在启动时就以 READ ONLY 模式打开，并持续应用主库的redo日志。这意味着：
- 所有
SELECT、CREATE VIEW、WITH子句、物化视图刷新（DBMS_MVIEW.REFRESH）都可正常执行 - 任何显式DML（
INSERT、UPDATE、DELETE）都会立即报错：ORA-16000: database open for read-only access - 不需要设置
ADG_REDIRECT_DML，该参数对物理ADG完全无效，SHOW PARAMETER adg_redirect_dml在物理备库上查不到 - 也不需要手动停MRP、开只读、再启MRP——19c中
ALTER DATABASE OPEN READ ONLY和RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT可同时生效
为什么报表查询看不到最新数据？常见延迟原因
物理ADG的“实时查询”不是绝对实时，延迟取决于网络、I/O、归档传输模式和应用速率。排查要点：
- 确认主库启用
FORCE LOGGING：否则NOLOGGING操作不会被复制，备库对应块始终为空或过期 - 检查传输方式：使用
SYNC或ASYNC影响延迟，但19c默认ASYNC已足够低（通常 MAXIMUM AVAILABILITY + 超低延迟网络 - 查备库同步状态：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED='YES'对比主库V$LOG_HISTORY，差值 >2 表示积压 - 避免在备库执行大排序/全表扫描：物理ADG不支持备库端创建索引或收集统计信息（会触发DML），统计信息必须从主库导出后手工导入
想让报表库“带写入能力”？别硬改物理ADG
如果业务要求报表库同时接收少量配置更新（如 UPDATE config_table SET value = 'x'），物理ADG做不到，强行绕过只会失败。可行路径只有一条：
- 放弃物理ADG，改用
LOGICAL STANDBY，并确保主库所有目标表有主键或启用ROW MOVEMENT - 在逻辑备库上执行：
ALTER DATABASE START LOGICAL STANDBY APPLY，再调用DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', '4') - 设置
ADG_REDIRECT_DML = TRUE（仅在此场景下生效），且必须配合DBMS_LOGSTDBY.SKIP白名单控制哪些表允许重定向 - 注意：逻辑备库的DML重定向是“主库发来的DML被转发执行”，不是你在备库连上去直接敲
UPDATE——后者仍会报ORA-16000
最易被忽略的一点：很多人花半天调 ADG_REDIRECT_DML，却没意识到自己连的是物理备库。先跑 SELECT DATABASE_ROLE, GUARD_STATUS FROM V$DATABASE ——返回 PHYSICAL STANDBY 就别碰DML重定向了，那不是你的工具箱里的锤子。
