如何通过数据哨兵在Oracle 12c中监控并配置EM 13c的容灾告警？

本文共计1093个文字，预计阅读时间需要5分钟。

相关专题：

oracle 12c 容灾环境不能直接用 data guard broker 的“数据哨兵”（data guard broker）做实时监控告警——它本身不提供告警通道，必须通过 enterprise manager 集成才能触发邮件、snmp 或 webhook 通知。

为什么 Data Guard Broker 自带的 DGMGRL 和 SHOW CONFIGURATION 不发告警

Data Guard Broker 是一个配置与故障切换协调工具，DGMGRL 中的 SHOW CONFIGURATION 或 VALIDATE DATABASE 只返回状态文本，不写入 ALERT_LOG，也不调用通知子系统。EM 13c 的告警规则无法自动捕获这些输出。

常见错误现象：

• DBA 在 DGMGRL 里看到 STATUS = ORA-16664，但 EM 里没收到任何告警
• 手动执行 VALIDATE DATABASE 'standby_db' 返回失败，但历史告警列表为空
• 启用了 Fast-Start Failover，但主库宕机后没有邮件通知

根本原因：Broker 的状态变更不会触发 Oracle 的 SERVERERROR 事件，也不会写入 DBA_OUTSTANDING_ALERTS 视图。

Enterprise Manager 13c 必须用“目标监控”而非“自定义SQL”来捕获 Data Guard 异常

EM 13c 对 Data Guard 的原生支持依赖于 Management Agent 收集的内置指标，不是靠 SQL 查询 V$DATAGUARD_STATS 或 V$ARCHIVE_DEST_STATUS。后者容易漏报（比如归档传输延迟未达阈值时就已积压）。

实操建议：

• 确保 Management Agent 版本 ≥ 13.4.0.9.v2，且 OMS 是 13.4.0.9 或打过补丁 32198287
• 在 EM 控制台中，进入目标数据库 → “监控” → “所有指标”，勾选以下关键指标：Data Guard Transport Lag (seconds)、Data Guard Apply Lag (seconds)、Data Guard Role
• 不要在“作业”里新建 SQL 脚本轮询 DBA_LOGSTDBY_EVENTS——该视图只记录逻辑备库事件，物理备库为空
• 确认 agentTZRegion 与数据库时区一致，否则时间类阈值判断会偏移

配置告警规则时，Transport Lag 和 Apply Lag 的阈值不能设为相同值

这是最常被忽略的兼容性陷阱。物理备库中，Transport Lag 指日志从主库传到备库归档目录的时间差；Apply Lag 指日志应用到备库数据文件的时间差。二者数值差异可能达数分钟，尤其在高并发 DML 场景下。

参数差异影响：

• 若将两者阈值都设为 60 秒，Apply Lag 很快超限，但 Transport Lag 还正常 → 导致误报“网络传输异常”
• 推荐设置：Transport Lag 阈值 ≤ 300 秒（5 分钟），Apply Lag 阈值 ≤ 600 秒（10 分钟）
• EM 13c 默认告警严重级别是 Warning，但 Data Guard 角色变更（如 PRIMARY → PHYSICAL STANDBY）应设为 Critical，否则不会触发邮件

注意：Apply Lag 指标在备库实例未 open（即 MOUNT 状态）时不可采集，此时 EM 显示“指标不可用”，不是配置错误。

测试告警是否真正生效，必须用真实故障场景而非模拟 SQL

很多团队用 ALTER SYSTEM SWITCH LOGFILE 加大归档压力来“测试”，但这种操作不会触发 Transport Lag 上升——因为日志仍能及时传输。真正有效的验证方式只有两种：

• 临时阻断主库到备库的归档传输路径（例如在防火墙 DROP 1521 或 22 端口），等 Transport Lag 自然增长至超限
• 在备库执行 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL，再等待 2 分钟，观察 Apply Lag 是否上升并触发告警

关键点：EM 告警有缓存周期，默认 5 分钟才刷新一次指标值。如果刚配完规则就立刻断网，可能要等至少 6 分钟才发出第一封邮件。别在第 3 分钟就去查 SMTP 日志。