ora-16000不是错误，而是dg物理备库以只读模式正常打开的状态提示；其本质是oracle主动标识数据库仅支持read only或read only with apply，不可执行dml/ddl，真正需排查的是mrp进程是否运行、主库是否启用force logging及应用层是否误在备库触发写操作。
ora-16000不是错误，是备库只读状态的正常提示
看到 ora-16000: database open for read-only access 不用紧张——它不是故障代码，而是 oracle 在物理备库以只读方式打开时主动返回的状态标识。真正的问题往往藏在背后：应用或脚本误以为这是“连接失败”，或试图在备库上执行写操作（如编译视图、刷新物化视图、创建 synonym、调用 dbms_service.start_service），才触发连锁报错（比如 ora-04045、ora-00604）。
关键判断点：只要 V$DATABASE.DATABASE_ROLE 返回 PHYSICAL STANDBY，且数据库已打开，ORA-16000 就是预期行为，不是修复目标。
检查MRP进程是否真正在运行，而非仅“接受日志”
很多团队看到 V$MANAGED_STANDBY 里有 ARCH 或 RFS 进程 RUNNING，就认为同步正常，但漏掉了最关键的 MRP0（Managed Recovery Process）。没有 MRP，日志只是躺在归档目录里，不会被应用，数据永远滞后。
- 执行
SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; - 期望结果是
STATUS = 'APPLYING_LOG'，且SEQUENCE#持续递增；若为WAIT_FOR_LOG或空行，说明 MRP 未启动 - 常见原因：备库仍处于
NOMOUNT或MOUNT状态未执行ALTER DATABASE OPEN READ ONLY；或主库未启用FORCE LOGGING导致日志不全，MRP 启动即中止 - 验证主库：运行
SELECT log_mode, force_logging FROM v$database;，必须同时为ARCHIVELOG和YES
READ ONLY 和 READ ONLY WITH APPLY 的实际差异
Oracle 19c 支持两种只读打开方式，但底层行为和适用场景不同，选错会导致“看似打开了，实则没同步”：
-
ALTER DATABASE OPEN READ ONLY：数据库只读，但 MRP 默认不自动启动；需额外执行RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; -
ALTER DATABASE OPEN READ ONLY WITH APPLY：12c+ 引入的语法糖，等价于上面两步合并；它会立即启动 MRP 并保持日志实时应用，这才是 ADG（Active Data Guard）的正确启用姿势 - 注意：如果执行
OPEN READ ONLY WITH APPLY后 MRP 仍未 RUNNING，大概率是归档中断或存在未解决的 GAP（可用SELECT * FROM V$ARCHIVE_GAP;检查）
帆软/报表工具连备库报 ORA-16000 的真实原因与绕过方式
帆软这类工具在首次访问视图或执行元数据查询时，可能隐式触发对象验证（revalidation），而验证过程需要写临时对象或更新数据字典——这在只读备库上必然失败，报出 ORA-04045 套 ORA-16000。
- 最直接解法：在主库上批量重新编译所有相关视图，命令如
EXEC UTL_RECOMP.RECOMP_SERIAL('NCC20');；确保主库编译成功后，等待重做日志同步到备库 - 检查帆软 SQL 是否含 DDL 隐式调用（如
CREATE SYNONYM、DBMS_MVIEW.REFRESH），这些必须移除或改走主库 DBLink - 若必须用备库承载查询负载，禁止任何依赖“运行时编译”的逻辑；可提前在主库生成物化视图并定期刷新，再通过 DBLink 查询物化视图，避开对备库结构的写依赖
真正容易被忽略的是：MRP 进程状态和主库 FORCE LOGGING 是硬性前提，缺一不可；而应用层报 ORA-16000 时，90% 的情况其实该去查主库对象状态和同步链路，而不是在备库上折腾打开模式。
