v$archive_dest_status比v$archive_dest更有效，因其聚合传输、归档、应用三阶段实时状态，error非空才表真故障；主库查询才有意义，status为error或deferred时须先查error字段。
查V$ARCHIVE_DEST_STATUS比V$ARCHIVE_DEST更有效
V$ARCHIVE_DEST只存配置，不反映实时状态；真正要看错误，得盯V$ARCHIVE_DEST_STATUS。它聚合了传输、归档、应用三阶段的健康信号，ERROR列非空才是真问题。常见错误如ORA-09285（备库目录权限不足）、ORA-16038（日志被重用但未传完），都直接写在这里。
执行时注意：该视图在主库查才有意义（备库上DEST_ID = 2通常为空）；若STATUS是ERROR或DEFERRED，先别动参数，先看ERROR字段具体值。
ERROR字段为空但同步卡住？检查TRANSPORT_LAG和APPLY_LAG
ERROR列为空不代表一切正常。当备库MRP0不动、V$ARCHIVE_GAP为空，但V$DATAGUARD_STATS里TRANSPORT_LAG或APPLY_LAG持续增长，说明日志已发到备库、但没应用——问题出在备库本地，比如：
-
standby_file_management设为MANUAL，主库新增数据文件后，备库没手动建，MRP0遇到UNNAMED文件就静默停住 - 备库ASM磁盘组缺失主库使用的路径（如
+DATADG1），但alert.log里可能只报ORA-01111，不显式说缺磁盘组 -
RECOVERY_MODE不是MANAGED REAL TIME APPLY，而是IDLE或空，说明ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE根本没执行成功
LOG_ARCHIVE_DEST_2配置中VALID_FOR漏写会隐身失效
RAC环境尤其容易踩这个坑：LOG_ARCHIVE_DEST_2必须含VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)。否则主库切换角色（比如switchover后原主变备），归档目标自动失效，V$ARCHIVE_DEST_STATUS里STATUS变成INACTIVE，ERROR却为空——因为Oracle认为“这配置本来就不该在当前角色生效”，不报错，只沉默。
验证方法：在主库运行SHOW PARAMETER log_archive_dest_2，逐字核对输出是否含VALID_FOR子句；若无，用ALTER SYSTEM SET log_archive_dest_2='...' SCOPE=BOTH重配，再ALTER SYSTEM ARCHIVE LOG CURRENT触发一次归档，观察V$ARCHIVE_DEST_STATUS是否转为VALID。
ORA-00397这类参数不一致错误不会出现在V$ARCHIVE_DEST_STATUS里
V$ARCHIVE_DEST_STATUS管传输链路，不管参数一致性。ORA-00397这种错误来自Data Guard内部校验，发生在switchover或broker操作时，提示类似Parameter DB_UNIQUE_NAME has different values on primary and standby。它不写进任何V$视图，只出现在alert.log或DGMGRL输出里。
排查路径很明确：
- 主备库分别执行
SHOW PARAMETER db_unique_name、SHOW PARAMETER log_archive_config、SHOW PARAMETER fal_server - 特别注意大小写和空格——
'ORCLDG'和'orclDG'在Oracle里算不同值 - 修改后必须重启实例（或至少
ALTER SYSTEM RESET加SCOPE=SPFILE），仅ALTER SYSTEM SET不生效
参数不一致的问题，往往在切换前毫无征兆，一到switchover就爆ORA-16775或ORA-00397——这是最容易被忽略的“静默风险点”。
