validate database是dgbroker主备库健康检查核心手段，仅校验结构一致性（如scn连续、归档可达），不保证逻辑一致；报ora-16653或卡住多因备库未启用实时应用或存在日志gap。
用 VALIDATE DATABASE 检查单个库的连通性与归档状态
这是最常被跳过的一步，但几乎所有后续操作失败（比如 ENABLE CONFIGURATION 卡住）都源于这里没过。Broker 不会主动告诉你主库归档关了、备库监听挂了、或者时间不同步，它只在 VALIDATE 时才报具体子错误。
执行前确保：主库是 OPEN、备库是 MOUNT（不是 READ ONLY），且两边 DG_BROKER_START=TRUE 已生效（需重启实例）。
-
VALIDATE DATABASE会检查：LOG_ARCHIVE_DEST_2是否指向正确DB_UNIQUE_NAME、归档是否开启（ARCHIVE LOG LIST显示Archive Mode: Enabled）、监听是否响应、tnsnames.ora条目是否匹配、FORCE LOGGING是否启用 - 若返回
ORA-16810: multiple errors or warnings detected，立刻补查：SHOW DATABASE VERBOSE <db_name></db_name>—— 重点看Health Check和Warning字段 - 常见漏项：
LOG_ARCHIVE_CONFIG缺少对方DB_UNIQUE_NAME，例如写成'DG_CONFIG=(pri)'而不是'DG_CONFIG=(pri,sto)'
用 SHOW CONFIGURATION VERBOSE 看整体状态和滞后指标
这个命令输出里真正有用的不是“Configuration Status”，而是每个数据库节点下的 Transport Lag、Apply Lag 和 Estimated Startup Time。它们直接反映同步质量，而不是 Broker 的“自评”。
-
Transport Lag> 0 表示主库 redo 还没传到备库磁盘（检查LOG_ARCHIVE_DEST_2的SYNC/ASYNC和网络延迟） -
Apply Lag> 0 表示备库已收到但还没应用完（检查 MRP 进程是否运行：SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY；若为APPLYING_LOG才正常） - 如果
Estimated Startup Time是unknown，说明备库控制文件不是从主库拷贝来的，或STANDBY_FILE_MANAGEMENT=AUTO没开，导致 Broker 无法预估恢复耗时
用 SHOW DATABASE <db_name> topwaitEvents</db_name> 定位性能瓶颈
当 Apply Lag 持续增长，但 MRP 显示运行中，问题往往不在传输层，而在备库内部等待。这时候 topwaitEvents 比 AWR 更快暴露根因。
- 高频现象：
log file sync高等待 → 主库COMMIT太频繁，且用了SYNC模式；enq: TX - row lock contention→ 备库正在应用某条 DML，而该行正被其他会话锁住（ADG 开启读写时容易触发） - 注意：
topwaitEvents只显示当前实例最近 5 个等待事件，不保留历史。若 lag 突然飙升后回落，得在飙升窗口内立即执行 - 不要只盯着 “
db file sequential read”，它可能是正常索引扫描；优先看带enq、latch、log file前缀的事件
为什么 SHOW CONFIGURATION 显示 SUCCESS 却实际不同步
Broker 的 SUCCESS 只代表配置参数合法、连接可达、进程能启停，并不校验数据一致性。一个典型陷阱是：主库归档日志被手动删过，但备库还没来得及应用，此时 SHOW CONFIGURATION 仍绿，但 SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG 在主备库上已出现断号。
- 真健康 =
VALIDATE DATABASE无警告 +SHOW DATABASE ... recvQentries返回空集 +SHOW DATABASE ... sendQentries返回空集 -
recvQentries非空？查V$ARCHIVE_DEST_STATUS的STATUS和ERROR列，常见ORA-16057: DGID not set表示DB_UNIQUE_NAME在LOG_ARCHIVE_DEST_2中拼错 - 别依赖 Broker 自动修复——它不会帮你补传缺失归档，也不会重做控制文件。一旦发现序列断号，必须手工拷贝并注册
