ORA-16766是MRP0进程已终止的结果，需查trace定位根因：ORA-01111/01157表明UNNAMED文件缺失，ORA-15041为ASM空间耗尽，ORA-65169系PDB文件未同步，修复后须验证v$archived_log中APPLIED='YES'连续3~5条。
ora-16766 不是独立错误，而是 redo apply 进程（mrp0）已退出的“结果快照”——必须先定位 mrp0 为何终止，而不是反复执行 edit database ... set state='apply-on'。
查 MRP0 是否真在运行，别被 DG Broker 的“Intended State”骗了
DG Broker 显示 Intended State: APPLY-ON 只代表你下过指令，不代表 MRP0 在跑。真实状态看 v$managed_standby：
-
PROCESS = 'MRP0'且STATUS = 'APPLYING_LOG'才算正常； - 如果查不到
MRP0行，或 STATUS 是WAIT_FOR_LOG/ERROR/NOT ACTIVE，说明它已挂掉； - 常见假象：
ARCH和RFS都在，但没MRP0——归档日志收得进来，就是不应用。
看 MRP0 的 trace 文件，错误码才是关键线索
MRP0 挂掉后会在 background_dump_dest 下生成 trace 文件，文件名含 _mrp0_。直接搜 ERROR 行，90% 的根因藏在这里：
-
ORA-01111/ORA-01157：备库缺数据文件，路径不存在或名字是UNNAMEDxxxxx； -
ORA-15041：ASM 磁盘组空间耗尽（比如DG_DATA01），MRP0 启动时创建临时文件失败； -
ORA-65169：12c PDB 场景下，主库新建 PDB 的数据文件没同步到备库对应路径，MRP0 遇到 DDL 就卡死； -
ORA-01274：备库缺少standby_file_management=auto，或db_create_file_dest未设，导致无法自动建文件。
修复前先确认 DG Broker 自身是否可信
如果 show configuration 显示 Configuration Status: ERROR，Broker 可能已失联或状态滞留，盲目操作会掩盖真实问题：
- 用
tnsping验证网络通不通（注意服务名带_DGMGRL后缀）； - 查
ps -ef | grep dmon，确保dmon进程活着； - 查
show parameter dg_broker_start，值必须是TRUE且scope=BOTH，否则重启库就失效； - 如果备库处于
RESTRICTED模式，dmon连不进去，Broker 就永远显示 ERROR，哪怕 SQL*Plus 能登录。
常见修复动作要匹配具体错误类型
不要无差别执行 alter database recover managed standby database disconnect，它可能掩盖底层文件缺失问题：
- 遇到
ORA-01111：先查v$datafile找出UNNAMED文件，用alter database create datafile '重建；' as ' ' - 遇到
ORA-15041：立刻清理 ASM 磁盘组（删归档、扩盘），再手工启动 MRP：alter database recover managed standby database using current logfile disconnect； - 遇到
ORA-65169（PDB 场景）：主库导出 PDB，备库用 RMANrestore pluggable database+recover补齐文件，再开库； - 所有修复后，必须等
v$archived_log中最新归档的APPLIED = 'YES'连续出现 3~5 条，才算真正追平。
最易忽略的一点：MRP0 启动失败往往不是单次错误，而是某次失败后 Broker 自动停掉进程并锁死状态——所以不能只看当前日志，得翻 2 小时内的 trace，找第一个报错的源头。
