dg_broker_start必须设为TRUE且重启实例，否则DGMGRL连接失败、配置创建报ORA-16532；还需满足DB_UNIQUE_NAME互异、PDB启用、LOG_ARCHIVE_CONFIG双向配置及_DGMGRL监听四项硬性条件。
dg_broker_start 必须为 TRUE，否则后续所有 Broker 操作都会失败——这是最常被跳过的一步，也是后续 dgmgrl 连不上、配置创建报 ORA-16532 的根本原因。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
确认主备库基础状态是否达标
Data Guard 不是“配完参数就能跑”的功能，它依赖几个硬性前提。缺一不可，且必须在启用 Broker 前验证：- 主库和备库的
db_unique_name必须不同，且已在tnsnames.ora中正确定义为可解析的服务名（例如PROD5H1和PROD5H2） - 主库必须处于
ARCHIVELOG模式，且已开启FORCE LOGGING：alter database force logging; - 主库必须有至少一组 Standby Redo Log（SRL），组数建议 ≥ Online Redo Log 组数 + 1；大小必须 ≥ 最大 Online Redo Log 文件
- 主备库的
log_archive_config必须互相包含对方的db_unique_name，例如：'DG_CONFIG=(PROD5H1,PROD5H2)' - 主库的
log_archive_dest_2必须指向备库服务名，并启用AFFIRM（若用最高可用性模式）或至少NOAFFIRM（最高性能模式）
Broker 配置前必须打开的三个开关
Broker 不是“启动即生效”，它依赖三个关键初始化参数，漏设任意一个都会导致CREATE CONFIGURATION 失败或配置无法启用：
-
dg_broker_start = TRUE：必须在spfile中设置并重启实例（ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH不生效） -
dg_broker_config_file1和dg_broker_config_file2必须指向可写的 ASM 或文件系统路径，且两个路径不能相同；Oracle 会自动管理这两个二进制配置文件，无需手动编辑 - 主备库的
local_listener必须正确指向本机监听器（如(ADDRESS=(PROTOCOL=TCP)(HOST=localhost)(PORT=1521))），否则 Broker 无法建立内部连接
DGMGRL> CREATE CONFIGURATION ... 卡住数分钟后报 ORA-16625: cannot reach database "PROD5H2"，本质就是 local_listener 解析失败或监听未真正注册服务。
用 dgmgrl 创建配置时的关键动作顺序
dgmgrl 是命令行工具，不是图形界面，所有操作都依赖精确的连接语法和执行顺序：
- 先连主库：
dgmgrl sys/<password>@PROD5H1</password>（注意这里用的是tnsnames.ora中定义的服务名，不是 SID） - 执行：
CREATE CONFIGURATION 'my_dg_config' AS PRIMARY DATABASE IS 'PROD5H1' CONNECT IDENTIFIER IS 'PROD5H1'; - 再添加备库：
ADD DATABASE 'PROD5H2' AS CONNECT IDENTIFIER IS 'PROD5H2' MAINTAINED AS PHYSICAL; - 启用前务必检查：
SHOW CONFIGURATION VERBOSE;—— 若显示DISABLED或ERROR，不要直接ENABLE，先查SHOW DATABASE VERBOSE 'PROD5H2';看具体哪项检查失败（常见是 SRL 缺失或归档传输未通） - 最后启用：
ENABLE CONFIGURATION;
DB_FILE_NAME_CONVERT 和 LOG_FILE_NAME_CONVERT 必须在备库的 spfile 中设置（不是主库），且值要成对、路径末尾带斜杠。
验证同步是否真实生效的最小检查集
Broker 配置成功 ≠ 数据真的在同步。必须人工触发并观察日志流：- 主库切一次日志：
ALTER SYSTEM SWITCH LOGFILE; - 立刻查主库归档目标状态：
SELECT DEST_ID, STATUS, PROTECTION_MODE, DESTINATION, ERROR FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID IN (1,2);——ERROR列必须为空，STATUS为VALID - 查备库是否收到并应用：
SELECT SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG WHERE NAME IS NOT NULL ORDER BY SEQUENCE# DESC FETCH FIRST 5 ROWS ONLY;—— 最新几条的APPLIED应为YES - 查实时延迟：
SELECT VALUE FROM V$DATAGUARD_STATS WHERE NAME = 'apply lag';—— 若返回+00 00:00:00表示无延迟；若为UNKNOWN，说明 Redo Apply 还没真正启动（常因备库未ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT）
MOUNT 状态后，必须手动执行恢复命令，Broker 不会自动帮你启动 Redo Apply；哪怕配置已 ENABLE，没这句命令，日志就堆在归档目录里不动。 
