第一眼需确认主备库角色与日志应用状态是否“活着”：主库应为primary、备库为physical standby且mounted；同步延迟≤1（通过v$archived_log与v$log_history序列号比对）；rfs和mrp0进程必须正常运行，standby redo log至少一组active或current。
检查主备库角色与同步状态是否实时一致
容灾环境是否可用，第一眼要看主备库当前角色和日志应用是否“活”着，而不是只看配置有没有写对。很多DBA查完V$DATABASE里OPEN_MODE是MOUNTED就以为备库正常，其实它可能早已停止接收日志。
- 主库执行：
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE FROM V$DATABASE;——确认是PRIMARY且PROTECTION_MODE匹配预期（如MAXIMUM PROTECTION） - 备库执行：
SELECT DATABASE_ROLE, OPEN_MODE, PROTECTION_MODE, GUARD_STATUS FROM V$DATABASE;——必须是PHYSICAL STANDBY、MOUNTED（非READ ONLY或READ WRITE），GUARD_STATUS为ALL或STANDBY - 同步延迟验证：
SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE APPLIED = 'YES' AND DEST_ID = 2;对比主库SELECT MAX(SEQUENCE#) FROM V$LOG_HISTORY;，差值≤1才算实时；若差值≥5，说明传输或应用已卡住
验证日志传输与应用链路是否真正打通
光看序列号没用，得确认日志从主库LGWR发出、经网络到达备库RFS、写入STANDBY REDO LOG、再被MRP进程读取并应用的全链路是否畅通。常见故障点在RFS进程挂掉或MRP没启动，但V$MANAGED_STANDBY里状态却显示“IDLE”。
- 主库查传输状态：
SELECT DEST_NAME, STATUS, TRANSMIT_MODE, AFFIRM, VALID_ROLE FROM V$ARCHIVE_DEST WHERE DEST_ID = 2;——STATUS必须是VALID，AFFIRM为YES（尤其MAXIMUM PROTECTION下） - 备库查接收与应用进程：
SELECT PROCESS, STATUS, CLIENT_PROCESS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS IN ('RFS', 'MRP0');——RFS状态应为IDLE（表示有连接、无新日志待收），MRP0状态必须是APPLYING_LOG，且SEQUENCE#持续递增 - 查
STANDBY REDO LOG是否被使用：SELECT GROUP#, THREAD#, SEQUENCE#, STATUS FROM V$STANDBY_LOG;——至少有一组状态是ACTIVE或CURRENT；全为UNASSIGNED说明没启用或大小/组数不匹配
模拟故障切换前必须跑通的三项实操验证
Switchover不是命令敲完就结束，中间任何一步失败都会导致业务中断。不能只依赖ALTER DATABASE COMMIT TO SWITCHOVER返回成功，要分步验证每阶段是否真能推进。
- 先做预检：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;——结果必须是TO STANDBY（主库）或SESSIONS ACTIVE（备库）。如果是NOT ALLOWED，说明日志没同步完或存在活跃会话 - 执行切换第一步后（主库
COMMIT TO SWITCHOVER），立刻查备库：SELECT DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;——应变为PRIMARY且SWITCHOVER_STATUS为TO STANDBY；若仍是PHYSICAL STANDBY，说明切换卡在中间态，需查ALERT.LOG中ORA-16139等错误 - 新主库打开PDB前，务必验证补丁一致性：
SELECT action, version, patch_id FROM dba_registry_history ORDER BY action_time DESC FETCH FIRST 1 ROWS ONLY;——主备库patch_id必须完全一致，否则PDB会hang在WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK
OEM告警是否真能捕获Data Guard关键异常
OEM默认规则对ORA-16XXX类错误完全失效，不手动干预就等于没监控。运维看到“无告警”就以为环境健康，实际可能已连续三天报ORA-16057（Destination disabled），只是没人收到通知。
- 登录OEM → Setup → Monitoring → Metric and Policy Settings → 找到自定义SQL指标，确认查询语句是：
SELECT MESSAGE FROM V$DATAGUARD_STATUS WHERE TIMESTAMP > SYSDATE - 1/1440 AND DEST_ID IS NOT NULL AND UPPER(MESSAGE) LIKE '%ORA-16%' - 重点验证两个过滤条件：
DEST_ID IS NOT NULL（排除主库本地日志干扰）、SYSDATE - 1/1440（即最近1分钟，不能用TRUNC(TIMESTAMP)，否则索引失效） - 手动触发一次测试告警：在备库执行
ALTER SYSTEM SWITCH LOGFILE;，再人为制造一条错误（如ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;），5秒后查V$DATAGUARD_STATUS是否出现ORA-16057，再看OEM是否推送告警
真实容灾可用性不取决于配置是否“看起来完整”，而取决于每次日志传输是否落盘、每个切换步骤是否可中断回退、每条关键错误是否能10秒内触达责任人。最容易被忽略的是V$DATAGUARD_STATUS里的瞬时错误——它们不进DBA_OUTSTANDING_ALERTS，也不写ADR，只在内存视图里存活几分钟，过期即丢。
