备库MRP0卡在APPLYING_LOG但sequence不推进，八成是UNNAMED文件导致，根本原因是STANDBY_FILE_MANAGEMENT未设为AUTO或DB_FILE_NAME_CONVERT路径映射不全，需检查参数、补全规则并手动重命名UNNAMED文件。
备库MRP0卡在APPLYING_LOG但sequence不推进，八成是UNNAMED文件
这不是归档缺失，而是主库新增数据文件后，备库没生成对应文件，MRP0遇到UNNAMED000xx就静默挂起——不报错、不跳过、不重试。查v$managed_standby看到PROCESS='MRP0'且STATUS='APPLYING_LOG'，但SEQUENCE#长期不变，基本可锁定该问题。
根本原因在于STANDBY_FILE_MANAGEMENT没设为AUTO，或虽设为AUTO但DB_FILE_NAME_CONVERT未覆盖新路径（比如PDB用+DATA/orcl/pdb1/，而转换规则只写了+DATA/orcl/→+DATA/orcldg/，漏了子目录层级）。
- 先确认当前值：
SHOW PARAMETER STANDBY_FILE_MANAGEMENT，必须是AUTO - 再查
DB_FILE_NAME_CONVERT是否匹配所有可能路径：SELECT NAME, VALUE FROM V$PARAMETER WHERE NAME = 'db_file_name_convert'; - 若发现
UNNAMED文件，立刻停MRP：RECOVER MANAGED STANDBY DATABASE CANCEL;
主库新建PDB或数据文件后，备库alert.log出现ORA-01111和ORA-01193
ORA-01111表示“name for data file xxx is unknown - rename to correct name”，ORA-01193说明“data file xxx is not the same as the original”，两者常一起出现。这说明主库已创建文件并写入redo，但备库因路径映射失败或磁盘组不存在，无法自动创建，只能留个占位符UNNAMED。
典型场景：主库用本地文件系统建PDB，路径是/u01/oradata/orcl/pdb2/；备库ASM里没对应别名或DB_FILE_NAME_CONVERT没配这一层，MRP0就卡住。
- 检查备库ASM是否有目标磁盘组：
SELECT NAME, STATE FROM V$ASM_DISKGROUP; - 手动创建缺失路径（如用
ASMCMDmkdir），或改用ALTER SYSTEM SET DB_FILE_NAME_CONVERT动态补全规则 - 切回MANUAL模式，手工重命名：
ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00023' AS '+DATA/orcldg/pdb2/system01.dbf';
DUPLICATE FROM ACTIVE后同步仍断，缺的不是命令而是路径映射完整性
很多人以为DUPLICATE FROM ACTIVE DATABASE跑完就万事大吉，其实它只复制已有文件，不预置未来扩展路径。一旦主库后续新增PDB、表空间或临时文件，且路径不在DB_FILE_NAME_CONVERT和LOG_FILE_NAME_CONVERT范围内，同步立刻失效。
特别注意：RMAN默认不会校验这些参数是否覆盖全部潜在路径，错误只在MRP0真正尝试应用时暴露，且无明确报错提示。
- 主库新增前，先在备库确认
DB_FILE_NAME_CONVERT是否含通配逻辑（Oracle不支持正则，只能靠多条精确映射） - 对PDB场景，建议按PDB名单独配置一组转换规则，例如：
'+DATA/orcl/pdb1/', '+DATA/orcldg/pdb1/', '+DATA/orcl/pdb2/', '+DATA/orcldg/pdb2/' - 临时文件同样要管：
LOG_FILE_NAME_CONVERT必须包含tempfile路径，否则新建PDB的tempfile也会变成UNNAMED
备库v$archive_gap为空，但数据明显落后，该盯v$dataguard_stats里的apply lag
V$ARCHIVE_GAP只反映归档日志是否收全，不反映是否已应用。当apply lag持续增长（比如从0秒涨到300秒），而transport lag稳定在0，说明归档已到，但MRP0应用层卡住了——大概率就是前面说的UNNAMED文件或路径映射断裂。
此时v$managed_standby里MRP0状态可能还是APPLYING_LOG，极具迷惑性。必须交叉验证三处：
SELECT NAME, VALUE FROM V$DATAGUARD_STATS WHERE NAME IN ('apply lag', 'transport lag');SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0';tail -n 50 $ORACLE_BASE/diag/rdbms/orcldg/ORCLDG/trace/alert_ORCLDG.log | grep -E "(ORA-01111|ORA-01193|UNNAMED)"
路径映射不是一次配好就能一劳永逸的事，主库每新增一个PDB或表空间，都得回头核对DB_FILE_NAME_CONVERT是否覆盖其物理路径——这点最容易被忽略，也最难排查。
