备库mount状态是正常起点，不是故障信号；执行open read only前必须确保mrp已运行，否则同步停滞；ora-10458等错误表明前置条件未满足，需先recover补齐归档、校验force logging、db_unique_name及归档gap，再启用open read only with apply。
备库MOUNT状态是正常起点，不是故障信号
Oracle 19c物理备库在完成RMAN DUPLICATE或手动恢复后，默认停留在MOUNTED状态，这是设计使然——它意味着控制文件已加载、数据文件结构就绪，但尚未启动日志应用进程（MRP）或打开为只读。很多DBA误以为“没起来”，其实是没走完最后一步。
OPEN READ ONLY前必须确保MRP已运行
执行ALTER DATABASE OPEN READ ONLY后，数据库进入只读模式，但MRP0进程默认不自动启动；此时查询V$MANAGED_STANDBY会发现PROCESS = 'MRP0'行为空或STATUS = 'WAIT_FOR_LOG'。同步实际处于停滞状态。
- 正确做法：先启MRP，再开库，或直接用
ALTER DATABASE OPEN READ ONLY WITH APPLY - 若用
OPEN READ ONLY后补RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE，需确认log_archive_dest_2指向主库且网络通（否则MRP启动即失败） - 检查
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'，只有APPLYING_LOG才算真正开始同步
常见卡在MOUNT的硬性拦截点
即使命令写对，也会因底层条件不满足被Oracle静默拒绝启动MRP或OPEN，典型有：
-
ORA-10458：控制文件与数据文件头的CHECKPOINT_CHANGE#不一致，常见于RMAN DUPLICATE后漏掉RECOVER步骤，必须先执行RECOVER MANAGED STANDBY DATABASE补齐归档 -
ORA-12514：监听器没配静态服务，GLOBAL_DBNAME写成主库名（如orcl而非orcl_stby），导致ALTER DATABASE RECOVER内部连接自身失败 -
ORA-00308：MRP尝试拉取归档时找不到thread_X_seq_Y，需从主库拷对应归档到备库log_archive_dest_1目录
OPEN READ ONLY WITH APPLY为何有时也不生效
这个语法本应自动触发MRP，但如果执行后MRP0仍不RUNNING，说明前置条件未满足：
- 主库未启用
FORCE LOGGING（查SELECT force_logging FROM v$database，必须为YES） - 备库
db_unique_name与主库log_archive_config中声明的不一致（如主库设LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,orcldg)'，但备库db_unique_name实际是orclstd） - 归档存在GAP：执行
SELECT * FROM V$ARCHIVE_GAP，若有记录，必须手工补齐缺失SEQUENCE段
最易被忽略的是：MRP依赖后台网络连接发起日志拉取，而该连接走的是备库自身的TNSNAMES.ORA别名——如果这个别名指向错误地址或未配置，MRP会在日志里静默报错TNS-12541，但V$MANAGED_STANDBY里只显示WAIT_FOR_LOG。
