执行 REMOVE CONFIGURATION 后需手动清理 Broker 元数据文件、归档传输参数及备库 SRL，否则 19c+ 中 MRP0 仍运行、归档可能失败或激活报错。
确认 Broker 配置是否已被真正移除
执行 dgmgrl> remove configuration 后，控制台显示 “removed configuration”，但这只是删除了 broker 的内存元数据和配置快照，并不等于主备库已“断连干净”。尤其在 19c 及以后版本中，log_archive_dest_2、log_archive_config、fal_server 等参数虽会被自动清空（如日志中可见 alter system set log_archive_dest_2=''），但 v$managed_standby 中的 mrp0 进程仍可能持续 applying_log —— 这说明物理备库还在尝试拉日志，broker 虽停，底层 data guard 传输逻辑并未关闭。
- 务必检查：
SELECT PROCESS, STATUS FROM v$managed_standby;，若仍有MRP0 APPLYING_LOG或RFS IDLE，代表备库仍在监听主库归档，需手动干预 - 验证参数是否生效：
SHOW PARAMETER log_archive_config应返回空值或nodg_config；SHOW PARAMETER dg_broker_start必须为FALSE - 注意：11g 删除配置后 MRP 通常自动终止；19c 不再如此，这是版本行为差异，不是操作遗漏
停掉 dg_broker 并清理 .dat 元数据文件
dg_broker_start=FALSE 是硬性前提，否则重启实例后 Broker 可能自动加载残留配置。而两个 .dat 文件（dr1*.dat 和 dr2*.dat）是 Broker 的持久化存储，哪怕 Broker 已停，只要文件还在，下次设回 TRUE 就会原样恢复旧配置 —— 所以删文件不是“可选步骤”，而是必须动作。
- 先查路径：
SHOW PARAMETER dg_broker_config_file1和SHOW PARAMETER dg_broker_config_file2 - 再停 Broker：
ALTER SYSTEM SET dg_broker_start=FALSE SCOPE=BOTH;（主备库都要执行） - 最后删文件：用
oracle用户执行rm <code>dr1*.datdr2*.dat，不要只 rename，避免误触发 - 常见坑：文件路径不在
$ORACLE_HOME/dbs？某些 RAC 或 ASM 环境下可能指向+DATA或恢复区，需按参数值精准定位
清理归档传输与备库关联参数
Broker 删除后，主库里那些曾为备库服务的归档参数并不会自动消失，它们仍驻留在 SPFILE 中，下次重启或手动 ALTER SYSTEM 时可能意外激活，导致归档失败或报错 ORA-16057。这不是 Broker 的问题，而是 Data Guard 基础配置层的残留。
- 需要显式 unset 的关键参数包括：
LOG_ARCHIVE_DEST_2（及对应LOG_ARCHIVE_DEST_STATE_2）、LOG_FILE_NAME_CONVERT、DB_FILE_NAME_CONVERT、STANDBY_FILE_MANAGEMENT、FAL_SERVER、FAL_CLIENT - 操作建议：
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;，而不是直接RESET（后者在 19c+ 对某些参数不支持） - 特别注意：
STANDBY_ARCHIVE_DEST在 12c+ 已废弃，若存在应一并清掉，否则可能干扰后续单机归档路径逻辑
备库转独立库前的必要收尾
如果目标是把物理备库彻底踢出 DG 架构、变成普通 standalone 数据库，光停 Broker 和删参数远远不够。备库当前仍处于 MOUNT 状态且有 SRL（Standby Redo Logs），这些组件会阻碍 OPEN RESETLOGS，也容易在后续 DBID 修改中引发 ORA-01184 错误。
- 先停应用：在备库执行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; - 再删 SRL：
SELECT GROUP# FROM V$STANDBY_LOG;→ 对每个GROUP#执行ALTER DATABASE DROP STANDBY LOGFILE GROUP n; - 激活前检查：
SELECT DBID, NAME FROM V$DATABASE;确认当前 DBID，避免和主库冲突（尤其克隆环境） - 最后才是
ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;→SHUTDOWN IMMEDIATE→STARTUP MOUNT→ALTER DATABASE OPEN RESETLOGS;
最易被跳过的点是 Standby Redo Logs：不删就直接 OPEN RESETLOGS，Oracle 会拒绝并报错，但错误信息并不直指 SRL，而是笼统提示 “control file not current” 或 “media recovery required” —— 这个卡点，得提前想到。
