mrp进程卡住是因为主备库在线重做日志大小不一致：主库8gb日志归档被备库200mb日志组拒绝应用，触发ora-00354等错误；必须停mrp、删除并重建备库v$log日志组使其与主库完全一致，再补全v$archive_gap缺口。
为什么重做日志大小不一致会卡住mrp进程
oracle 19c dg物理备库的mrp（managed recovery process）在应用归档日志时，会严格校验每个归档文件所对应的在线重做日志（online redo log）的大小是否与本地当前日志组配置匹配。这不是“建议”，而是硬性校验逻辑：当主库切换到一个8 gb的在线日志组（如你按最佳实践从200 mb升到8 gb），而备库仍维持200 mb的日志组时，mrp在解析该归档头时发现log_file_size字段值（8 gb）远超本地v$log.file_size（200 mb），会直接拒绝应用，并静默停在wait_for_log或报ora-00354 / ora-00353类错误——但告警日志里往往只写“corrupt header”，不提大小问题。
检查主备重做日志大小是否对齐
别猜，直接查两库的V$LOG和V$STANDBY_LOG：
- 主库执行：
SELECT GROUP#, BYTES/1024/1024/1024 AS GB FROM V$LOG ORDER BY GROUP#; - 备库执行同样语句——注意不是查
V$STANDBY_LOG，它只反映SRL（Standby Redo Log）大小，而MRP校验的是主库归档所映射的在线日志大小 - 若主库最大日志组为
8GB，备库却显示0.2GB，这就是根因
常见误区：以为只要SRL大小 ≥ 主库在线日志就行。错。SRL大小影响的是RFS接收能力，MRP应用阶段校验的是“归档来源日志”的原始尺寸，与SRL无关。
备库重做日志组必须与主库完全一致
Oracle官方明确要求：物理DG中，主备库的V$LOG.BYTES必须相等。不一致时，唯一合规解法是停MRP、重建备库日志组。步骤如下：
- 先停MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 删掉所有现有日志组（包括inactive和current）：
ALTER DATABASE DROP LOGFILE GROUP 1;（逐个执行） - 重建——大小、组数、成员数全部对齐主库：
ALTER DATABASE ADD LOGFILE GROUP 1 ('+DATA') SIZE 8G; - 确认：
SELECT GROUP#, STATUS, BYTES/1024/1024/1024 FROM V$LOG;输出应与主库一致 - 重启MRP：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
注意：不要试图用ALTER DATABASE RESIZE LOGFILE——该命令在19c备库上被禁用，会报ORA-01518。
同步恢复后必须验证归档缺口
即使日志大小对齐，MRP重启后也未必立刻追平。因为之前卡住期间可能已产生V$ARCHIVE_GAP。务必补全：
- 在备库查缺口：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP; - 去主库找对应归档：
LIST ARCHIVELOG FROM SEQUENCE <code>low_seqUNTIL SEQUENCEhigh_seqTHREADthread_num; - 拷贝后手动注册：
ALTER DATABASE REGISTER PHYSICAL LOGFILE '<code>full_path'; - 再启动恢复：
RECOVER AUTOMATIC STANDBY DATABASE;
最容易被忽略的一点：重做日志大小调整后，首次MRP启动时会跳过所有已存在的归档（哪怕没应用），只从最新接收到的日志开始——所以缺口一定得人工补，不能指望它自动续上。
