ora-16xxx报错不能只靠oem默认告警，因其轮询间隔长（5–15分钟）易漏瞬时错误，且默认不匹配ora-16*模式；须手动添加基于v$dataguard_status的自定义sql指标，并正确配置返回类型、阈值与采集频率。
ora-16xxx 报错为什么不能只靠 oem 默认告警
oem 的 data guard 监控默认不触发 ora-16xxx 类错误（比如 ora-16057、ora-16198）的邮件/短信告警，它更侧重于 broker 状态和延迟阈值。这些报错往往出现在归档传输失败、日志应用卡住、网络闪断等瞬间，oem 的轮询间隔（默认 5–15 分钟）容易漏掉——等你看到“redo apply lag”变红时，可能已经积压数小时日志。
实操建议：
- 不要依赖 OEM 的 “Critical Alert for Data Guard Errors” 规则，它默认不包含
ORA-16*模式匹配 - 必须手动在 OEM 中添加自定义指标：路径为
Setup → Monitoring → Metric and Policy Settings → Add Metric，类型选SQL Query - 查询语句必须用
V$DATAGUARD_STATUS而非DBA_OUTSTANDING_ALERTS，后者不实时捕获 ORA-16XXX（它们不走 ADR 告警通道）
用 SQL 查询实时抓取 ORA-16XXX 错误的正确写法
直接查 V$DATAGUARD_STATUS 是最可靠的方式，但要注意时间窗口和去重逻辑——同一错误可能在 1 分钟内重复刷出 20 条记录，脚本若不做控制会狂发告警。
实操建议：
- 推荐查询条件：
SELECT MESSAGE FROM V$DATAGUARD_STATUS WHERE TIMESTAMP > SYSDATE - 1/1440 AND UPPER(MESSAGE) LIKE '%ORA-16%'（查过去 1 分钟） - 必须加
AND DEST_ID IS NOT NULL过滤主库本地日志（主库V$DATAGUARD_STATUS也会有少量 ORA-16XXX，但无意义） - 避免用
TO_DATE或TRUNC处理TIMESTAMP字段，会强制全表扫描；用SYSDATE - n/1440保持索引可用（该视图在TIMESTAMP上有隐式索引） - 示例一行命令快速验证：
sqlplus -s / as sysdba <pre class="brush:php;toolbar:false;">SELECT MESSAGE FROM V$DATAGUARD_STATUS WHERE TIMESTAMP > SYSDATE - 1/1440 AND DEST_ID IS NOT NULL AND UPPER(MESSAGE) LIKE '%ORA-16%';</pre>
自定义脚本告警的三个关键防抖点
脚本跑通不等于能上线——没处理好防抖，运维半夜会被同一错误刷屏 50 条短信。
实操建议：
- 状态文件锁：每次执行前检查
/tmp/dg_ora16_alert.lock是否存在且未超时（用stat -c '%Y' /tmp/dg_ora16_alert.lock判断是否 >5 分钟），避免并发重复告警 - 错误指纹化：对
MESSAGE做哈希（如echo "$msg" | md5sum | cut -d' ' -f1），只对新指纹发告警，旧指纹跳过 - 静默期兜底：首次告警后写入
/tmp/dg_ora16_last_alert时间戳，后续 15 分钟内相同错误指纹直接忽略（即使锁文件已过期）
用 OEM 自定义 SQL 指标时最容易配错的参数
OEM 里加 SQL 指标看着简单，但四个字段一填错，指标就永远显示 “N/A” 或 “0”，还查不出原因。
实操建议：
-
Return Type必须选Number，哪怕你查的是字符串——OEM 强制要求返回数值型，所以得包装成COUNT(*)，别直接返回MESSAGE -
Warning Threshold和Critical Threshold填0和1，不是 “大于 0” 就告警，而是 “结果集行数 ≥ Critical Threshold” 才触发 -
Collection Frequency设为1分钟（别信文档说的最小 5 分钟，实测 1 分钟可行） - 测试阶段务必勾选
Run this metric immediately after saving，否则改完配置要等下一个轮询周期才生效
复杂点在于：ORA-16XXX 往往是链式反应——一个 ORA-16198 可能 3 秒后引发 ORA-16057，再 2 秒触发 ORA-16766。脚本或 OEM 指标只能捕捉“现象”，真正定位得立刻查 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL 后的 ARCHIVE_LAG_TARGET 和 LOG_ARCHIVE_DEST_n 配置。
