执行 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*.dat dr2*.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” —— 这个卡点，得提前想到。