新主库未配置Standby Redo日志是MRP静默停摆的根因；需确保其数量≥Online Redo组数+1、大小匹配，并重建控制文件、同步口令文件、修正log_archive_dest_2指向下游备库。
备库没配 Standby Redo 日志，MRP 会静默停摆
主从切换后备库收不到新日志，最常被忽略的根因是：**切换后的“新主库”（原备库）没建 standby redo 日志**。这不是归档传输问题，而是角色反转后，新主库仍需为下游备库（如果存在）或自身未来再切回 standby 做准备——而 mrp 进程只有在有 standby redo 的前提下，才能持续接收并应用来自上游的 redo 流。否则它会在应用完最后一段归档后卡在 wait_for_log，看似运行中，实则已停。
- 检查当前备库（即刚切过来的新主库）是否真有 Standby Redo：
SELECT group#, thread#, bytes, archived, status FROM v$standby_log;—— 若无记录或全为UNASSIGNED，说明缺失 - Standby Redo 组数必须 ≥ Online Redo 组数 + 1，且大小要 ≥ 最大 online redo 组；例如 online 有 3 组 × 50M，则至少建 4 组 × 50M
- 创建命令示例：
ALTER DATABASE ADD STANDBY LOGFILE GROUP 4 '/u01/oradata/db/standby_redo04.log' SIZE 50M;，注意路径要有写权限、不在快速恢复区（FRA）内 - 创建后务必重启 MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;，否则旧进程不识别新组
log_archive_dest_2 指向的是“新主库”，但参数还留着旧角色配置
切换完成后，原备库变成主库，它的 log_archive_dest_2 应该指向下游备库（如有），而不是继续指向“已不存在的旧主库”。但很多运维习惯性只改 db_unique_name 和 LOG_ARCHIVE_CONFIG，却漏掉这个关键归档目标。结果就是新主库根本没尝试发日志，下游自然收不到。
- 查当前主库（刚切过来的）归档目标：
SELECT dest_id, destination, valid_for, status FROM v$archive_dest WHERE dest_id = 2; - 确认
destination是下游备库的 TNS 别名（如SERVICE=stby2），不是旧主库别名；valid_for必须含(ONLINE_LOGFILE, PRIMARY_ROLE)，而非(STANDBY_LOGFILE, STANDBY_ROLE) -
status必须为VALID；若为ERROR或空，看 alert.log 搜索ORA-16055或ORA-12514，大概率是 tnsnames.ora 缺失该别名或 SERVICE_NAME 写错 - 修改示例：
ALTER SYSTEM SET log_archive_dest_2='SERVICE=stby2 VALID_FOR=(ONLINE_LOGFILE,PRIMARY_ROLE) DB_UNIQUE_NAME=stby2' SCOPE=BOTH;
切换后备库控制文件未更新，导致 Standby Redo 无法激活
即使你手动加了 Standby Redo 文件，如果控制文件仍是切换前的旧版本（比如用的是切换前备份的 standby controlfile），Oracle 会拒绝启用这些日志组，v$standby_log 里显示 UNASSIGNED，MRP 也起不来。
- 验证控制文件是否为最新：
SELECT created, dbid, name FROM v$database;和SELECT checkpoint_change# FROM v$database;，对比切换前快照 - 最稳妥做法：切换成功后，在新主库上立即执行一次
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/standby_control.ctl';，再传给下游备库用 - 不要复用旧 standby 控制文件——它不含新主库的在线日志序列和 SCN 连续性信息，会导致后续所有 redo 接收失败
口令文件未同步，新主库连不上下游备库的监听
主备切换后，新主库发起日志传输时，需要以 SYS 身份连接下游备库的监听器。这个身份认证依赖口令文件。如果仍用旧口令文件（比如直接复制自老主库），而新主库的 ORACLE_SID 或 DB_UNIQUE_NAME 已变，就可能触发 ORA-01033 或 ORA-12514，表现为 ARC 进程报“connection refused”，但 tnsping 却通——因为 tnsping 不校验口令。
- 检查新主库口令文件名是否匹配当前
ORACLE_SID：ls $ORACLE_HOME/dbs/orapw<code>ORACLE_SID（Linux）或orapw<code>ORACLE_SID.ora（Windows） - 重建命令：
orapwd file=$ORACLE_HOME/dbs/orapw<code>ORACLE_SIDpassword=sys_passwordentries=10 force=y - 确保下游备库监听器已加载该新主库的
GLOBAL_DBNAME（即DB_UNIQUE_NAME），否则即使口令对，也会被监听器拒收
实际排查时，最容易被跳过的是第一项：以为“能切过去就代表环境 OK”，却没意识到 Standby Redo 是新主库维持 DG 链路的基础设施，不是可选项。只要下游还有备库，或者你计划未来再切回去，这个配置就必须在切换完成后的 5 分钟内补全。
