Data Guard Broker是Oracle 19c强制推荐的管理入口，跳过它将丧失角色同步与故障自动感知能力；其正常运行需DG_BROKER_START=TRUE（spfile持久化）、监听器GLOBAL_DBNAME匹配、ADD DATABASE时SERVICE名带完整域名、LOG_ARCHIVE_DEST_n的VALID_FOR严格区分主备角色，且故障常表现为沉默降级而非报错。
Data Guard Broker 不是可选组件，而是19c中强制推荐的管理入口；跳过它直接用SQL*Plus手动切换，等于放弃角色状态同步和故障自动感知能力。
DBMS_DG.CREATE_CONFIG 之前必须关闭所有隐式Broker干扰
很多人执行 CREATE CONFIGURATION 报 ORA-16525 或 ORA-16532，根本原因不是权限不足，而是主库或备库的 DG_BROKER_START 参数仍为 FALSE，或者数据库已启动但 Broker 进程未真正加载。
- 检查当前状态：
SELECT VALUE FROM V$PARAMETER WHERE NAME = 'dg_broker_start';—— 必须为TRUE，且该参数需在spfile中持久化，重启后仍生效 - 若曾手动启停过 Broker（如用
DGMGRL的ENABLE CONFIGURATION失败过），先执行ALTER SYSTEM SET DG_BROKER_START=FALSE SCOPE=BOTH;，再重启实例，再设回TRUE - 确保主备库的
listener.ora中监听器名与tnsnames.ora中定义的全局数据库名（GLOBAL_DBNAME）一致，Broker 依赖这个名称做实例注册，不匹配会导致DGMGRL CONNECT成功但后续命令报 ORA-16571
DGMGRL 中 ADD DATABASE 的 SERVICE 名必须带域名后缀
在 DGMGRL 里执行 ADD DATABASE 时，如果只写 db_unique_name 对应的 TNS 别名，Broker 会尝试用默认域名解析连接字符串，而生产环境往往使用自定义域名（如 prod.example.com），导致重做传输静默失败——日志里看不到错误，但 ARCHIVED_THREAD# 和 APPLIED_THREAD# 始终不同步。
- 正确写法：
ADD DATABASE mystandby AS CONNECT IDENTIFIER IS 'mystandby.prod.example.com' MAINTAINED AS PHYSICAL; - 验证方式：在备库上运行
SELECT DEST_ID, STATUS, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;，若ERROR字段非空，大概率是 SERVICE 解析失败 - 不要依赖
tnsping成功就认为可用——tnsping只测监听器连通性，Broker 还需要通过 SERVICE 名拿到实例的DB_UNIQUE_NAME和角色信息，这一步失败不会报显式错误
VALID_FOR 参数冲突会让 Broker 自动禁用归档路径
Broker 启用后，LOG_ARCHIVE_DEST_n 的 VALID_FOR 配置会被严格校验。例如主库设了 LOG_ARCHIVE_DEST_2='SERVICE=stby VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)'，但备库的同编号路径也配置了相同值，Broker 检测到“同一 DEST_ID 在两个角色下都声称有效”，会直接将该路径 STATUS 置为 INACTIVE，且不记录任何警告。
- 主库物理备库路径必须用：
VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) - 备库对应路径必须用：
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE) - 检查手段：
SHOW DATABASE VERBOSE myprimary;和SHOW DATABASE VERBOSE mystandby;，重点关注每个LogXptMode对应的LogArchiveDest是否显示Enabled: YES - 一旦发现
Enabled: NO，别急着改参数——先用DISABLE DATABASE+ENABLE DATABASE让 Broker 重新加载配置，否则改完参数也不生效
Broker 最容易被忽略的复杂点在于它不报错，只沉默降级：路径失效、传输中断、角色识别偏差，常常表现为延迟缓慢爬升、REDO TRANSPORT LAG 从秒级跳到小时级，但 DGMGRL SHOW CONFIGURATION 仍显示 Success。真出问题时，第一反应不该是查日志，而是立刻 SHOW DATABASE VERBOSE 看每个关键属性的实际取值——那才是 Broker 当前“相信”的事实。
