REMOVE CONFIGURATION比手动删.dat文件更安全，因其同步清理DMON内存快照、V$DATAGUARD_CONFIG视图条目及.dat文件三处状态；手动删除仅破坏文件一致性，易致ORA-16532或ORA-16603等错误。
broker配置失效不能直接删.dat文件再enable——必须用remove configuration配合主备库同步操作，否则必然触发ora-16603或ora-16748。
为什么REMOVE CONFIGURATION比手动删dr1*.dat更安全
Broker的元数据不只存在.dat文件里，还缓存在DMON进程内存和数据库字典视图中。手动rm只会破坏文件一致性，而REMOVE CONFIGURATION会主动清理三处状态：DMON内存中的配置快照、V$DATAGUARD_CONFIG视图条目、以及.dat文件本身。跳过这步直接删文件，重启后DMON会尝试加载损坏的残留结构，导致DGMGRL连不上或报ORA-16532: data guard broker is not configured。
常见错误现象：
-
DGMGRL> SHOW CONFIGURATION返回空或DISABLED，但ps -ef | grep dmon显示进程仍在运行 - 执行
ENABLE CONFIGURATION卡住，日志里反复出现ORA-16713: command timed out - 主库
SELECT * FROM V$DATAGUARD_CONFIG只返回LOCAL一行，说明Broker已丢失备库感知能力
执行REMOVE CONFIGURATION前必须确认的三件事
Broker是跨实例共享状态，主库和备库必须严格按顺序操作，漏掉任一环节就会中断信任链。
-
ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=BOTH;，然后确认ps -ef | grep dmon无输出；若仍有进程，需kill -9并重启实例 - 备份两个配置文件：
cp $ORACLE_HOME/dbs/dr1*.dat /backup/dg_broker_$(date +%Y%m%d).bak（注意RAC环境可能有dr2、dr3） - 清空日志目录：
rm -f $ORACLE_HOME/rdbms/log/drn*.log $ORACLE_HOME/rdbms/log/drc*.trc，避免旧trace干扰新配置加载
REMOVE和CREATE必须主备库同步执行
主库执行DISABLE DATABASE <db_unique_name>后，必须立刻在备库上执行相同命令；只有当双方都完成DISABLE，才能在任意一端执行REMOVE CONFIGURATION。否则会报ORA-16748: broker cannot open the primary database。
重建时的关键校验点：
- 主库
SHOW PARAMETER LOG_ARCHIVE_DEST_2中SERVICE值必须是备库TNS别名，不是IP+端口直连 - 主库上
tnsping <standby_tns_alias>和sqlplus sys/<pwd>@<standby_tns_alias> as sysdba必须全部成功 - 备库
LOG_ARCHIVE_DEST_STATE_1必须为ENABLE，否则ENABLE CONFIGURATION会静默失败
重建后验证不能只看Configuration Status: SUCCESS
状态栏显示SUCCESS只是Broker层面通了，真正决定是否可用的是传输与应用链路。第一次ENABLE后，立刻执行：
-
SHOW DATABASE VERBOSITY <db_unique_name>，盯住Redo Transport和Log Apply两行是否为ON - 主库查
V$ARCHIVE_DEST_STATUS，确认STATUS = VALID且ERROR列为空 - 备库查
SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;，确保RFS和MRP都在运行
最容易被忽略的是LOG_ARCHIVE_FORMAT参数一致性——主备库若不一致，VALIDATE DATABASE会卡在Waiting for archive log，但Broker状态仍显示SUCCESS。
