MRP进程未启动或卡在WAIT_FOR_GAP时,首要确认其是否运行:查v$managed_standby无MRP0记录或状态非APPLYING_LOG,需手动启动并确保备库处于MOUNT或READ ONLY WITH APPLY状态。
备库归档日志已传到,但数据就是不应用,第一反应不是网络或权限问题,而是MRP进程根本没跑起来。执行V$MANAGED_STANDBY查不到MRP0记录,或者状态是WAIT_FOR_GAP,就说明它停在了缺失日志处。
SELECT PROCESS, STATUS, SEQUENCE# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('MRP0', 'MRP');
APPLYING_LOG,手动启动:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
MOUNT或READ ONLY WITH APPLY状态,OPEN READ ONLY下MRP不会工作日志根本没发过去,自然谈不上应用。常见错误是ORA-16191(主库LNS无法登录备库)和ORA-12154(TNS解析失败),本质都是认证或连通性断了。
ORA-16191几乎全是密码文件问题:主备库SYS密码不一致,或备库缺少orapw<sid>文件,或REMOTE_LOGIN_PASSWORDFILE没设成EXCLUSIVE或SHARED
ORA-12154是TNS配置问题:主库log_archive_dest_2里写的service_name在tnsnames.ora中不存在,或监听没起、防火墙拦了端口SELECT DEST_NAME, STATUS, ERROR FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;,ERROR列直接暴露根因日志传过去了,但中间缺了几段,MRP会静默卡住——不报错、不推进、也不告警,只在V$ARCHIVE_GAP里留痕。这是最隐蔽的同步中断原因。
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
V$ARCHIVED_LOG里APPLIED='YES'的最大SEQUENCE#是否落后主库SEQUENCE#的归档路径,手动拷到备库,再用ALTER DATABASE REGISTER PHYSICAL LOGFILE注册主库新增表空间或数据文件,备库磁盘不够或参数设为MANUAL,就会生成UNNAMED00135这类占位文件,后续日志应用直接失败,报FILE MISSING。
SELECT FILE#, NAME FROM V$RECOVER_FILE WHERE ERROR = 'FILE MISSING';
SHOW PARAMETER STANDBY_FILE_MANAGEMENT,生产环境必须是AUTO
ALTER DATABASE CREATE DATAFILE '/path/to/UNNAMED00135' AS '/real/path/file01.dbf';,但治标不治本,得立刻扩容并切回AUTO真正棘手的从来不是单点故障,而是多个条件叠加:比如MRP卡在GAP上,同时备库又缺空间,而你只盯着TNS连通性调了一整天。排查时别跳步,按“传输→接收→应用”三层顺序验证,每层都得看到明确证据,而不是凭感觉猜。