排查Data Guard同步异常须先查alert.log中的ORA-160xx/ORA-1057/ORA-1110等关键错误，再查v$archive_dest_status确认传输与应用状态，用dgmgrl验证broker配置一致性，备库缺文件时勿删UNNAMED文件而应手动创建并检查DB_FILE_NAME_CONVERT与磁盘空间。
看 alert.log 里有没有 ORA-160xx / ORA-1057 等关键错误
oracle data guard 同步异常时，alert.log 是第一手线索来源，不是“可能有”，而是“一定得先查”。重点盯住以 ora-160 开头的错误（如 ora-16057：dg broker 配置缺失；ora-16055：归档传输被拒绝）和 ora-1057（重做应用失败）、ora-1110（数据文件丢失）这类底层 i/o 或恢复类报错。
常见误操作是只扫一眼最近几行就下结论。实际要：
- 用 tail -n 500 $ORACLE_BASE/diag/rdbms/ 拉出全部错误
- 注意时间戳是否连续——断续出现的 ORA-16057 往往说明 broker 连接反复中断，而非单次配置错误
- 如果看到 MRP0: Background Managed Recovery process started 后紧跟着 ORA-01111，基本可锁定是备库缺数据文件
查 v$archive_dest_status 确认归档传输卡在哪一环
v$archive_dest_status 是判断“主库发没发出去”“备库收没收到”的核心视图。别只看 STATUS = VALID 就放心，关键字段是：
- ERROR：非空即故障，例如 ORA-12541: TNS:no listener 表示主库连不上备库监听器
- TRANSMIT_MODE 和 ARCHIVED_THREAD#：确认是否启用了实时传输（ASYNC 或 SYNC），以及归档线程是否对齐
- RECOVERY_MODE：值为 MANAGED REAL TIME APPLY 才算在实时应用；若为 IDLE，说明 MRP 进程根本没跑起来
- STANDBY_LOGFILE_COUNT 和 STANDBY_LOGFILE_USED：如果后者长期为 0，大概率是 standby redo log 没配或大小不匹配
执行 SELECT DEST_ID, STATUS, ERROR, RECOVERY_MODE FROM v$archive_dest_status WHERE DEST_ID IN (1,2);（假设备库是 DEST_ID=2）比翻文档快得多。
用 dgmgrl 检查 broker 配置与状态一致性
当 DG Broker 参与管理时，SQL*Plus 里的视图可能滞后于 broker 内部状态。必须用 dgmgrl 连上去验证：
- 运行 connect sys/，再 show configuration —— 若输出含 Warning: ORA-16596，说明 broker 记录的 db_unique_name 和实际实例不一致，常见于克隆备库后未更新 broker 配置
- show database verbose " 中重点关注 Transport Lag 和 Apply Lag：前者 >0 表示归档没传完，后者 >0 表示已传但没应用完
- 若显示 State: TRANSIENT 或 State: UNKNOWN，不要直接 enable，先 validate database " 查具体失败点
备库缺文件时，别急着删 UNNAMEDxxx 文件
当备库报 ORA-01157: cannot identify/lock data file 且文件名是 UNNAMED00042 这类，说明主库新增了表空间，但备库因磁盘满、路径不存在或 DB_FILE_NAME_CONVERT 配错，导致自动创建失败，Oracle 用占位符顶上了。
此时最常踩的坑是：
- 直接 rm $ORACLE_HOME/dbs/UNNAMED00042，结果下次日志应用又报错，因为占位符删了但重做里“创建文件”的操作还在队列里
- 在主库用 alter tablespace xxx add datafile ... 后立刻切归档，没等备库同步完就查状态，造成误判
正确做法是：
- 先确认备库目标路径是否有足够空间、权限是否正确
- 检查 STANDBY_FILE_MANAGEMENT 是否为 AUTO（show parameter STANDBY_FILE_MANAGEMENT）
- 若路径没问题，手动在备库创建对应文件：ALTER DATABASE CREATE DATAFILE '/u01/app/oracle/product/19c/dbhome_1/dbs/UNNAMED00042' AS '/oradata/stdby/users02.dbf';
- 再启动 MRP：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
真实环境里，DB_FILE_NAME_CONVERT 配错和备库磁盘满这两件事，占了文件缺失类问题的八成以上。但它们在 alert.log 里往往只体现为一行 ORA-01111，后面跟着个 UNNAMED 占位符——这个细节，很多人扫一眼就跳过去了。
