必须先确认Broker已启用且数据库处于MOUNT/OPEN状态，否则DGMGRL连接失败或显示配置状态未知；需确保dg_broker_start=TRUE生效、监听正常、TNS可解析，并优先用CONNECT sys/password@db_unique_name连接。
如何用 DGMGRL 连接并检查 Data Guard 配置状态
必须先确认 broker 配置已启用且数据库处于 mount 或 open 状态，否则 dgmgrl 连不上或显示 configuration status is unknown。连接前确保 dg_broker_start=true 在主备库都生效（需重启实例或用 alter system set dg_broker_start=true scope=both），且监听正常、tns 别名可解析。
实操建议：
- 用
sqlplus / as sysdba登录后执行SHOW PARAMETER dg_broker_start双端验证 -
DGMGRL连接时优先用CONNECT sys/password@db_unique_name，避免依赖本地tnsnames.ora中的别名拼写错误 - 运行
SHOW CONFIGURATION前，先ENABLE CONFIGURATION（如果显示为 DISABLED）；若报错ORA-16532: Data Guard broker configuration does not exist，说明还没用CREATE CONFIGURATION初始化过
主备切换时为什么 SWITCHOVER TO 失败，常见卡点在哪
最常卡在备库未同步完成或角色校验失败。Broker 会严格检查 LogXptMode（传输模式）、ApplyLagThreshold（默认 30 秒）、TransportLagThreshold（默认 30 秒）是否超限，任一不满足就拒绝切换。
实操建议：
- 切换前务必先
SHOW DATABASE VERBOSE 'standby_db_name'，重点看Transport Lag和Apply Lag是否为0 seconds；若非零，先等日志追平，或临时调大阈值：EDIT DATABASE 'standby_db_name' SET PROPERTY ApplyLagThreshold=300 - 确保备库
LOG_ARCHIVE_DEST_STATE_2是ENABLE，且DB_UNIQUE_NAME在主库的LOG_ARCHIVE_DEST_2中拼写完全一致（大小写敏感） - 如果报错
ORA-16664: unable to receive the result from a database，大概率是备库监听没起来，或LOCAL_LISTENER指向了不可达地址
Broker 配置被意外破坏后，如何安全重建而不影响现有同步
Broker 元数据损坏（比如误删 dg_broker_config_file1/2 文件）会导致 SHOW CONFIGURATION 报错或返回空，但物理日志传输通常不受影响——因为那是靠归档参数和网络连通性驱动的。重建的关键是不中断当前 ARCHIVE_LAG_TARGET 或 LOG_ARCHIVE_DEST_n 的工作流。
实操建议：
- 先停掉 Broker：
DISABLE CONFIGURATION→EXIT→ 在主备库分别执行ALTER SYSTEM SET dg_broker_start=FALSE，再删掉旧的 broker 配置文件（路径见SHOW PARAMETER dg_broker_config_file1） - 重启两个实例（或至少执行
ALTER SYSTEM SET dg_broker_start=TRUE），再用DGMGRL重新CREATE CONFIGURATION，注意AS PRIMARY必须指向当前真正为主库的DB_UNIQUE_NAME，不能反 - 重建后立即
ADD DATABASE加入备库，再ENABLE CONFIGURATION；此时 Broker 会自动触发一次全量配置校验，只要网络和归档路径没问题，不会中断正在传输的日志流
用脚本调用 DGMGRL 自动化时，为什么命令总“假成功”
DGMGRL 脚本模式下默认不校验命令实际效果，比如 SWITCHOVER TO 'new_primary' 返回 Succeeded，但后台可能卡在等待 apply lag 清零，而脚本已退出。更隐蔽的是，DGMGRL 在非交互模式下对错误码处理宽松，某些 ORA 错误只打屏不设退出码，导致 shell 脚本的 $? 永远是 0。
实操建议：
- 所有自动化脚本必须加显式状态轮询：执行
SWITCHOVER后，循环调用DGMGRL -silent执行SHOW DATABASE 'xxx' StatusReport，直到输出包含Role: PRIMARY且State: SUCCESS - 用
echo "SHOW CONFIGURATION" | DGMGRL /替代交互式输入，但要在末尾加2>&1 | grep -q "SUCCESS"判断真实结果，不能只信 exit code - 日志中留意
Warning:行——比如Warning: Using deprecated syntax或Warning: Property ... has inconsistent value，这些不会导致命令失败，但预示后续操作可能异常
Broker 的“自动化”本质是封装了部分 RMAN 和 SQL*Plus 操作，但它的状态机判断逻辑藏得深，一旦网络抖动或参数微小不一致，就容易出现“看起来成功、其实卡住”的情况。真要稳，就得自己补上状态断言，不能只信它最后一行输出。
