应结合时间上下文分析备库日志，用 tail -n 20000 alert.log | grep -b 3 -a 5 "ora-|wait_for_log|mrp0.*applying" 提取关键片段；查 v$managed_standby 中 mrp0 的 sequence# 是否冻结，再定位 ora-30036、ora-28374 等隐藏错误，并验证 db_file_name_convert 和 force logging 配置。
直接 grep ora- 不够，得加时间上下文
只跑 grep ora- 会漏掉关键线索——很多同步中断不是立刻报错，而是先卡住、再超时、最后退避重试。比如 ora-01111 和 ora-01157 常伴随 “unnamed” 数据文件出现，但错误行可能隔十几秒才写入日志，前面几行往往是“thread 1 advanced to log sequence”这类正常日志，掩盖了问题。
推荐用 tail -n 20000 alert_<code>DB_UNIQUE_NAME.log | grep -B 3 -A 5 "ORA-\|WAIT_FOR_LOG\|MRP0.*applying"：
- -B 3 拿错误前 3 行，常含时间戳和进程状态
- -A 5 拿后 5 行，能看到是否触发 recovery 或 cancel
- 同时匹配 WAIT_FOR_LOG 和 MRP0，比单查 ORA- 更早发现静默停滞
v$managed_standby 显示 applying_log，但 sequence# 不动就是假象
查 v$managed_standby 看到 PROCESS = 'MRP0' 且 STATUS = 'APPLYING_LOG'，不代表真在应用。如果 SEQUENCE# 连续 5 分钟没变，大概率是卡在某条日志上反复失败。
- 先确认是否有
MRP0行：没有就说明恢复根本没启动，需执行ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT - 有
MRP0但SEQUENCE#冻结，立刻查备库alert.log中最近 10 分钟内是否出现ORA-30036（undo 不足）、ORA-28374（TDE 密钥不一致）或ORA-01110（UNNAMED文件） - 别信
v$archive_gap返回空——它只反映接收缺口，不反映应用卡点。即使 gap 为 0，MRP 也可能因 undo 被覆盖而无限重试
ORA-30036 和 ORA-28374 都不报在备库 alert.log 的第一行
ORA-30036 实际源于主库 undo 压力，但错误日志会出现在备库 alert.log 中，且往往藏在 MRP 进程重试的中间段落里，不是开头。典型模式是：
MRP0: Applying archived log /u01/arch/1_12345.arc Errors in file /u01/diag/rdbms/stbydb/STBYDB/trace/STBYDB_mrp0_12345.trc: ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1' MRP0: Waiting for archive log 1_12346.arc
这时不能只看 alert.log，要立刻去主库查：
- SELECT UNXPSTEALCNT, SSOLDERRCNT FROM V$UNDOSTAT WHERE BEGIN_TIME > SYSDATE-1/24（>0 就证实 undo 被强占）
- SELECT EVENT, COUNT(*) FROM V$SESSION_EVENT WHERE EVENT LIKE 'enq: US%' GROUP BY EVENT（争用高说明事务阻塞）
ORA-28374 更隐蔽：密钥文件 ewallet.p12 在主备端 md5sum 不一致时，备库不会一上来就报错，而是等到第一个加密表空间的日志应用时才触发，且错误堆栈里可能混着 ORA-01110 和 ORA-01157，容易误判为数据文件损坏。
别跳过 DB_FILE_NAME_CONVERT 和 FORCE LOGGING 检查
这两个参数不报错，但会导致同步无声失效。
-
DB_FILE_NAME_CONVERT若未正确配置（比如主库路径含/oradata/PROD/，备库却写成/oradata/STBY/但实际目录是/u02/oradata/STBY/），新数据文件创建时会生成UNNAMED文件，后续所有涉及该文件的日志应用都失败，错误表现为ORA-01111+ORA-01110 -
FORCE LOGGING关闭时，主库某些 DML 可能不写 redo，备库自然无法同步。查主库：SELECT FORCE_LOGGING FROM V$DATABASE，必须为YES；若为NO，执行ALTER DATABASE FORCE LOGGING后还需切一次日志：ALTER SYSTEM SWITCH LOGFILE，否则已有归档仍不包含强制日志
真正难缠的不是报错本身，而是错误被日志滚动冲走、被重试掩盖、或藏在非标准路径的 trace 文件里。盯紧 MRP0 的 SEQUENCE# 变化节奏，比扫全量 alert.log 更快定位根因。
