Oracle 11g起已弃用dbconsole，Data Guard管理必须使用Enterprise Manager Cloud Control（OMS+Agent），需确保Agent运行、注册且DG插件已部署，并满足Broker启用、权限配置等条件。
EM 中添加 Data Guard 配置时，为什么 emctl start dbconsole 不起作用？
因为 oracle 11g 及之后版本已弃用 dbconsole，dg 管理必须依赖完整的 oracle enterprise manager cloud control（即 oms + agent 架构），而非单实例的 db control。你在 dg 主库或备库上执行 emctl start dbconsole，只会启动本地旧式控制台，它既不感知远端备库状态，也无法触发 data guard broker 的同步检查。
正确做法是：确保每个 DG 节点（主库、备库）都部署了 Oracle Management Agent，且该 Agent 已注册到中心 OMS；OMS 必须已加载 Data Guard Management Pack（需企业版许可）。
- 确认 Agent 状态：
emctl status agent—— 必须显示Agent is Running且目标列表含 DG 相关数据库 - 检查 OMS 插件：
emctl list plugins输出中应含oracle.sysman.ohs和oracle.sysman.dg - 若插件缺失，需手动部署：
emctl deploy plugin -plugin oracle.sysman.dg -oms_host <code>your_oms_host-oms_port 7788
在 EM Cloud Control 里看不到 Standby 数据库的“Switchover”按钮
这通常不是界面 bug，而是权限或配置层面的硬性限制。EM 对 DG 操作的呈现高度依赖底层 Broker 配置和用户角色。
关键条件有三个：Broker 必须启用、dg_broker_start=TRUE 在主备库均生效、当前登录 EM 的用户必须拥有 EM_ADMINISTRATOR 角色且被显式授予 DG_ADMIN 权限（仅靠 DBA 角色不够）。
- 验证 Broker 状态：
SELECT value FROM v$parameter WHERE name = 'dg_broker_start';—— 主备库都得是TRUE - 检查 Broker 配置文件位置：
SHOW PARAMETER dg_broker_config_file—— 确保主备库指向同一 ASM 或共享文件系统路径 - 在 EM 中，进入「Setup > Security > Administrators」，确认该用户勾选了
Data Guard Administrator权限项
EM 自动发现 DG 配置后，备库显示 “Not synchronized”，但实际 Redo Apply 正常
这是 EM 依赖的指标采集延迟或视图映射偏差导致的误报，常见于跨广域网（WAN）部署的 DG 集群。EM 默认每 5 分钟轮询一次 v$archive_dest_status 和 v$dataguard_stats，而网络抖动或高延迟可能让某次采样丢失 APPLIED_SCN 更新。
不要直接信“Not synchronized”红标，先交叉验证：
- 查真实应用进度：
SELECT to_char(applied_scn, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;（备库执行） - 比对主库最新归档：
SELECT max(first_time) FROM v$archived_log WHERE dest_id=1;（主库） - 检查传输延迟：
SELECT round((sysdate - last_apply_time)*24*60, 2) AS mins_behind FROM v$managed_standby WHERE process='MRP0';
若上述值均正常，可在 EM 中临时禁用该告警：进入「Targets > Databases > your_standby_db > Monitoring > All Metrics」，找到 Data Guard Synchronization Status，将收集频率调为 15 分钟，或关闭其告警阈值。
批量管理 50+ 个 DG 配置时，EM 控制台卡顿甚至超时
这不是浏览器问题，而是 OMS 默认未针对大规模 DG 场景优化查询逻辑。EM 在渲染 DG 拓扑页时，会并发拉取每个备库的 v$dataguard_stats、v$archive_dest、v$managed_standby 三张视图，当节点数超过 30，OMS JVM 堆内存和 JDBC 连接池很容易打满。
缓解方案优先级从高到低：
- 调大 OMS 内存：编辑
$OMS_HOME/bin/omsconfig.sh，将-Xms和-Xmx提升至至少8g（原默认常为 2g） - 限制拓扑刷新范围：进入「Setup > Monitoring > Metric Collection Settings」，将
Data Guard类指标的采集间隔统一设为 10 分钟以上 - 避免在 Web UI 中展开全部 DG 链路——改用 CLI 批量操作：
emcli sync; emcli get_targets -targets="DataGuardConfig:<code>your_dg_name"
真正的大规模场景（200+ DG 配置），必须拆分 OMS 实例或启用只读代理节点，单 OMS 实例硬扛会持续出现元数据锁争用，这点容易被忽略。
