重置前必须确认dg_broker_start=TRUE，否则DGMGRL命令全部失效；主备库需同步执行DISABLE DATABASE和REMOVE CONFIGURATION，再重启dmon进程，并验证MRP/RFS状态及switchover就绪性。
重置前必须确认 dg_broker_start=TRUE
Broker 命令（如 DGMGRL 中的 ENABLE、SWITCHOVER）全部失效，如果主备库任一端的 dg_broker_start 参数为 FALSE。这不是“重启后自动恢复”的设置，必须显式开启：
- 在 SQL*Plus 中执行
SHOW PARAMETER dg_broker_start，确认返回值为TRUE - 若为
FALSE，立即执行ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH; - 重启数据库不是必须操作，但需确保
dmon进程已拉起：ps -ef | grep dmon应有输出
ORA-16706 / ORA-16501 报错时别急着删配置
这些错误本质是 broker worker 无法与数据库实例或配置文件通信，常见原因包括：
-
DG_BROKER_CONFIG_FILE1和DG_BROKER_CONFIG_FILE2指向的两个.dat文件缺失、权限错误（非oracle用户属主）、或所在文件系统只读 - 磁盘空间不足（尤其
$ORACLE_HOME/rdbms/log/目录），导致 broker 日志写入失败 - SELinux 启用且策略拦截了
dmon对配置文件的访问（setenforce 0可临时验证） - 主备库的
DB_UNIQUE_NAME不一致，或 TNS 别名解析失败（tnsping必须通）
盲目执行 REMOVE CONFIGURATION 会丢失延迟设置、归档目标、保护模式等元数据，且后续重建极易触发 ORA-16603（configuration ID mismatch）。
安全重置角色需主备库同步执行 DISABLE + REMOVE
Broker 配置是跨实例共享状态，单边操作必然导致不一致。真正有效的重置流程是：
- 主库和备库**同时**执行：
DISABLE DATABASE <db_unique_name>;</db_unique_name>（注意不是DISABLE CONFIGURATION） - 再**依次**执行：
REMOVE CONFIGURATION;—— 此命令仅在配置中只剩一个库时才被允许 - 若备库报
ORA-16713: command timed out，说明监听未响应或网络不通，先排查lsnrctl status和防火墙 - 完成后，主备库都必须重启
dmon：先ALTER SYSTEM SET dg_broker_start=FALSE;，再=TRUE;
重置后必须验证 MRP/RFS 进程与 switchover 就绪状态
重建配置后，容易忽略的是底层日志传输链路是否真实生效：
- 在备库查：
SELECT PROCESS, STATUS, THREAD#, SEQUENCE# FROM V$MANAGED_STANDBY;确认MRP0（Managed Recovery Process）为APPLYING_LOG，RFS为IDLE或RECEIVING - 在主库查：
SELECT SWITCHOVER_STATUS FROM V$DATABASE;必须为TO STANDBY才能执行SWITCHOVER；若仍为NOT ALLOWED，说明 broker 未接管归档目标控制权 - 检查
LOG_ARCHIVE_DEST_n参数是否被 broker 自动覆盖：手工设置的归档路径会被 broker 忽略，一切以SHOW DATABASE VERBOSE输出为准
最常被跳过的一步是验证归档目标属性是否实时同步——broker 不会自动继承你之前手工配的 SYNC/ASYNC 或 DELAY，这些必须在 CREATE CONFIGURATION 后用 EDIT DATABASE ... SET PROPERTY 显式设定。
