ORA-01219在DG物理备库上属正常现象，因备库默认MOUNTED状态且禁止OPEN，仅允许查v$/x$固定视图；若MRP0进程运行且applied_seq#持续更新，则为预期行为，无需“修复”。
ora-01219 在 dg 备库上出现，根本不是“数据库没开”，而是备库处于 mounted 状态且未启用日志应用（managed recovery）——这是正常设计，不是故障。
为什么 DG 备库 select * from v$database 显示 MOUNTED 却报 ORA-01219？
DG 物理备库默认以 MOUNT 方式启动（不 OPEN），只为接收和应用归档日志。此时 v$database.open_mode 一定是 MOUNTED，所有用户表、数据字典视图（如 dba_tables）均不可查，仅允许访问 v$ / x$ 等固定视图 —— 这正是 ORA-01219 的触发条件。
这不是错误，是 Oracle DG 的安全机制：防止误操作写入备库。
- 物理备库不允许
ALTER DATABASE OPEN（除非转为快照备库或主库） - 执行
SELECT COUNT(*) FROM scott.emp必然报 ORA-01219 - 但
SELECT sequence#, applied FROM v$archived_log可以正常执行
如何确认日志是否正在应用（而非“卡住”）？
先排除“备库停在 MOUNTED 状态但没启动恢复”的常见误判：
- 检查当前是否已启动日志应用：
SELECT process, status, thread#, sequence# FROM v$managed_standby;—— 若无MRP0或MRP进程，说明未启动恢复 - 查看最近归档是否已接收：
SELECT max(sequence#) FROM v$archived_log WHERE dest_id = 2 AND applied = 'YES'; - 对比主库当前日志序列：
SELECT max(sequence#) FROM v$log;—— 差值过大（如 >5）且v$managed_standby中无活跃 MRP，则需手动启动
若确认未启动，执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
ALTER DATABASE OPEN 在物理备库上为何绝对禁止？
物理备库一旦执行 ALTER DATABASE OPEN（哪怕只读），会立即退出恢复模式，后续无法自动续接日志流，且可能因 SCN 不一致导致数据损坏。
- 只读打开（
OPEN READ ONLY）后，必须先SHUTDOWN IMMEDIATE，再STARTUP MOUNT，才能重新启动 MRP - 若误开并写入了任何数据（哪怕只是
CREATE TABLE），该备库即失效，需重建 - 真正需要只读查询的场景，应使用
ACTIVE DATA GUARD许可，并确保已启用：ALTER DATABASE OPEN READ ONLY;后立刻执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
ORA-01219 出现时，第一反应不该是“怎么打开库”，而是……
先跑这三行：
SELECT open_mode, database_role, protection_mode FROM v$database;
SELECT process, status, client_process, sequence# FROM v$managed_standby WHERE process IN ('MRP0', 'RFS');
SELECT archived_thread#, archived_seq#, applied_thread#, applied_seq# FROM v$archive_dest_status WHERE dest_id = 2;
如果 v$database.database_role 是 PHYSICAL STANDBY，且 v$managed_standby 中有运行中的 MRP0，那 ORA-01219 就是预期行为 —— 此时你该做的是用 SELECT ... FROM v$ 视图验证同步状态，而不是试图“修复”这个报错。
真正危险的信号是：MRP 进程不存在、v$archive_dest_status.applied_seq# 长期不更新、或 v$managed_standby.status 显示 WAIT_FOR_LOG 但主库已切日志多次 —— 这些才需要排查网络、归档传输参数（log_archive_dest_2）、密码文件一致性等底层问题。
