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/@PROD5H1（注意这里用的是 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，没这句命令，日志就堆在归档目录里不动。