必须显式执行remove database和remove configuration清除broker残留配置，否则重建同名配置会报ora-16623/ora-16603；同时需清理log_archive_dest_n参数及“失联归档”物理文件。
备库配置已停用但DG Broker仍残留怎么办
Oracle Data Guard Broker 的配置不会随数据库关闭或角色切换自动清理，停用备库后若未显式删除，dg_broker_config_file1 和 dg_broker_config_file2 里仍保留旧路径、监听配置和状态元数据，后续重建同名配置会报 ORA-16623 或 ORA-16603 错误。必须先从 Broker 中彻底移除，否则 DGMGRL 无法注册新配置。
操作前确认：DGMGRL 已连接到当前主库（不是原备库），且该 Broker 配置处于 DISABLED 状态：
SHOW CONFIGURATION VERBOSE;
若显示 DISABLED 且状态为 WARNING 或 FAILURE，说明配置已失效但未清理。执行以下步骤：
- 在
DGMGRL中执行REMOVE DATABASE 'db_unique_name_of_standby';—— 注意是原备库的db_unique_name，不是实例名 - 再执行
REMOVE CONFIGURATION;，这会清空整个 Broker 配置（包括主库条目） - 检查 $ORACLE_HOME/dbs/ 下两个 Broker 配置文件是否已被自动重命名（如加
.old后缀）；若仍在，手动rm掉它们 - 重启主库监听器和数据库实例，确保 Broker 相关后台进程（DMON）完全退出
删完 Broker 配置后，归档目录和控制文件记录还在
Broker 配置清理只影响元数据，不碰物理归档和控制文件记录。停用的备库若曾接收过归档，其 v$archived_log 中仍存在大量 DEST_ID 对应的已应用记录，这些记录会被 control_file_record_keep_time（默认 7 天）持续保留，但超期后元数据消失，RMAN 就再也看不见那些物理文件了——它们变成“失联归档”，只能靠 find /path/to/arch -name "*.dbf" -mtime +15 -delete 清理。
关键点：
- 别直接
rm -f *.dbf，先查v$archive_dest确认DEST_ID是否还指向该路径；若已无对应 DEST，说明该路径已废弃 - 执行
find命令前，务必确认当前无备份任务（如第三方工具）正在扫描该目录，否则可能中断备份 -
-mtime +15是安全缓冲值，比SYSDATE - 7多留 8 天，避免刚失效就删
RAC 环境下删备库配置要额外注意节点一致性
在 RAC 主库上删除 Broker 配置时，DGMGRL 默认只作用于当前连接节点。若未同步到所有实例，其他节点重启后可能重新加载旧 Broker 文件，导致 DMON 进程异常启动并报 ORA-16826。
必须做两件事：
- 所有 RAC 节点都执行一次
REMOVE CONFIGURATION;，不能只在一个节点操作 - 检查每个节点的
$ORACLE_HOME/dbs目录，确认dr1*.dat和dr2*.dat文件均被清除或重命名 - 修改
init.ora或 SPFILE 中的dg_broker_start=FALSE，防止实例重启时自动拉起 DMON
删完配置却收不到主库归档？检查 LOG_ARCHIVE_DEST_n 是否残留
Broker 配置删除后，主库的 LOG_ARCHIVE_DEST_2（或更高编号）可能仍保留着已停用备库的地址，比如 SERVICE=old_stby LGWR SYNC AFFIRM。这种残留会导致主库持续尝试传输归档，失败后不断写 ALERT.log，甚至引发 LNS 进程卡住。
查并清理方法：
- 在主库执行
SELECT dest_id, status, destination FROM v$archive_dest WHERE dest_id > 1;，找出指向已停用备库的dest_id - 执行
ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='' SCOPE=BOTH;（按实际dest_id替换） - 立刻触发一次日志切换：
ALTER SYSTEM SWITCH LOGFILE;，观察v$archive_dest_status中对应项是否变为INACTIVE - 最后执行
ALTER SYSTEM ARCHIVE LOG CURRENT;确保当前日志被归档，验证传输链路已真正断开
最易被忽略的是：Broker 配置删了，但 LOG_ARCHIVE_DEST_n 没清，主库仍在发归档；或者 find 清理归档时没核对 DEST_ID 是否已失效，误删了其他备库的归档路径。
