remove configuration 失败主因是 Fast-Start Failover 未禁用，需先执行 disable fast_start failover；再停备库 redo apply；删配置仅清 Broker 相关参数，手工参数需手动清理；主备库均须关闭 dg_broker_start 并删除元数据文件。
为什么 remove configuration 会失败？常见报错和前置条件
直接在 dgmgrl 中执行 remove configuration 报错，十有八九是因为 fast-start failover（fsfo）还开着。错误信息通常是：ora-16654: fast-start failover is enabled。这不是配置残留问题，而是 broker 的强制保护机制——只要 fsfo 启用，就绝不允许你一键清空整个 dg 配置，防止误操作导致高可用能力突然归零。
必须先手动禁用它：
DGMGRL> disable fast_start failover- 再确认状态：
DGMGRL> show configuration，看到Fast-Start Failover: DISABLED才算成功 - 如果备库还在接收日志，
remove configuration可能卡住或触发主库归档阻塞，所以建议提前停掉备库的 redo apply（alter database recover managed standby database cancel;）
执行 remove configuration 后，主库参数真被自动清理了吗？
是的，但只清理 Broker 管理的那部分。执行成功后，你会在主库 alert.log 里看到类似这几条自动执行的语句：
ALTER SYSTEM SET log_archive_dest_2='' SCOPE=BOTHALTER SYSTEM SET log_archive_config='nodg_config' SCOPE=BOTH-
ALTER SYSTEM SET dg_broker_config_file1='' SCOPE=BOTH（仅限某些版本）
但注意：这些只是“Broker 感知到的参数”。像 db_file_name_convert、log_file_name_convert、standby_file_management、fal_server 这些手工配置过的参数，remove configuration 完全不会碰——它们仍留在 SPFILE 里，下次重启可能引发异常归档或文件创建失败。
删完配置，备库还在连主库？检查 v$archive_dest 和网络残留
remove configuration 不等于物理断连。主库上仍可能存在未被清除的归档目标，尤其是当 log_archive_dest_2 被设为空字符串但 log_archive_dest_state_2 还是 ENABLE 时，LGWR 仍会尝试连接备库地址，造成 TNS 超时、lns 进程反复报错、甚至拖慢主库归档性能。
务必手动验证并收尾：
- 查真实归档目标：
SELECT dest_id, destination, status FROM v$archive_dest WHERE target = 'STANDBY';—— 若有输出，说明还没真正断开 - 彻底关闭该路径：
ALTER SYSTEM SET log_archive_dest_state_2=DEFER SCOPE=BOTH; - 重启监听器释放残留连接：
lsnrctl reload或lsnrctl stop && lsnrctl start - 检查
alert.log是否还有ORA-12170: TNS:Connect timeout occurred或lns类报错
备库没关 Broker 参数？别忘了两边都要动手
很多人只在主库操作，结果发现备库自己又悄悄连回去了，或者启动时报 ORA-16664: unable to receive the result from a database。因为 dg_broker_start 是实例级参数，主库关了，备库的 DMON 进程还在跑，它会持续尝试注册、拉取配置、甚至反向发起连接。
必须同步处理备库：
ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=BOTH;- 然后删掉 Broker 元数据文件（路径查
SHOW PARAMETER dg_broker_config_file）：rm -f /path/to/dr1*.dat /path/to/dr2*.dat - 如果备库已不再用作 standby，下一步就是
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;转成独立库，否则它始终处于“半吊子”状态
最常被跳过的动作是删元数据文件。Broker 关了但文件还在，下次手抖把 dg_broker_start 改回 TRUE，它会直接读旧配置复活，前功尽弃。
