备库数据文件缺失或路径错乱会导致MRP进程中断，报ORA-19527或ORA-01111等错误；需检查v$datafile一致性、db_file_name_convert配置、STANDBY_FILE_MANAGEMENT参数及NOLOGGING操作影响，并正确重建undo/temp文件和控制文件。
备库数据文件缺失或路径错乱导致同步中断
物理DG环境下，备库数据文件与主库不一致（比如文件名、路径、甚至大小不同）会直接阻断MRP进程，报ORA-19527或ORA-01111等错误。这不是归档传输问题，而是备库在应用重做时发现目标文件根本不存在或无法写入。
- 先确认是否真缺失：在备库执行
SELECT file#, name, status FROM v$datafile，比对主库v$datafile中同file#的name字段——尤其注意ASM别名、OMF生成的随机名（如+DATA/mydb/datafile/t2019.259.1018457031） - 若备库
name指向主库路径（如/u01/oradata/orcl/users01.dbf），说明db_file_name_convert未生效或配置错误；该参数必须写在备库spfile中，且重启startup mount才生效 - 若文件物理存在但状态为
RECOVER或OFFLINE，不要直接ALTER DATABASE DATAFILE ... ONLINE——MRP尚未启动，强行online会破坏一致性；应先停MRP、检查归档GAP、再恢复
主库新增数据文件后备库没自动创建
即使设置了STANDBY_FILE_MANAGEMENT=AUTO，备库仍可能漏建新数据文件，典型现象是MRP日志里反复出现ORA-01111: name for data file <n> is unknown - rename to correct name</n>，且v$datafile中对应file#的name显示为MISSINGnnnnn。
- 立即检查备库参数：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT——必须是AUTO，MANUAL模式下完全不会自动建文件 - 确认主库新增操作是否带
NOLOGGING：如果是CREATE TABLESPACE ... NOLOGGING，这部分变更不会进redo，备库自然无法感知；必须用LOGGING重建 - 临时补救：在备库手动执行
ALTER DATABASE CREATE DATAFILE '/path/to/MISSING00001' AS '<correct_path>'</correct_path>，路径必须严格匹配db_file_name_convert规则；之后重启MRP
UNDOTBS或TEMP文件不一致引发ORA-01157
备库的undotbs01.dbf或temp01.dbf损坏、丢失或路径错误时，MRP可能启动成功但几秒后崩溃，alert.log里出现ORA-01157: cannot identify/lock data file，且v$managed_standby中MRP0状态在APPLYING_LOG和WAIT_FOR_LOG间快速切换。
- 不要直接scp主库的
undotbs01.dbf覆盖备库——undo表空间结构与SCN强绑定，强行替换会导致后续应用失败 - 正确做法：在备库
startup mount状态下，执行ALTER DATABASE CREATE UNDO TABLESPACE undotbs2 DATAFILE '<new_path>' SIZE 100M</new_path>，再ALTER SYSTEM SET undo_tablespace='UNDOTBS2'，最后DROP TABLESPACE undotbs1 INCLUDING CONTENTS AND DATAFILES - 临时文件（tempfile）可直接删除重建：
ALTER DATABASE TEMPFILE '<old_path>' DROP INCLUDING DATAFILES</old_path>，再ALTER TABLESPACE temp ADD TEMPFILE '<new_path>' SIZE 100M</new_path>
控制文件版本不匹配导致MRP静默退出
备库控制文件不是从主库最新standby controlfile重建的，或者主库升级PSU后未重新生成控制文件，MRP可能看似启动成功，但v$managed_standby查不到MRP0记录，或状态始终为NOT ACTIVE。此时ps aux | grep mrp看到的进程往往是僵尸残留。
- 验证控制文件新鲜度：在备库执行
SELECT created, checkpoint_change# FROM v$database，对比主库同SQL结果——若checkpoint_change#远小于主库当前SCN，说明控制文件太旧 - 重建步骤：主库执行
ALTER DATABASE CREATE STANDBY CONTROLFILE AS '/tmp/stby.ctl'，scp到备库对应$ORACLE_HOME/dbs/或ASM路径，shutdown immediate后startup mount - 关键细节：如果备库用了OMF，控制文件路径可能是
+DATA/<db_unique_name>/CONTROLFILE/current.xxx</db_unique_name>，此时必须用ASMCMD cp拷贝，不能用scp，否则权限元数据丢失
实际处理中最容易被忽略的是：控制文件和密码文件的更新必须严格按顺序完成。先换控制文件、再换密码文件，中间不能有日志切换；否则MRP可能因认证失败而卡在WAIT_FOR_LOG，你以为是路径问题，其实只是sys连不上。
