Oracle Data Guard如何建立日常巡检与告警机制-Oracle-PHP中文网

日常巡检应聚焦4个核心视图的关键字段：v$database查database_role和open_mode；v$dataguard_stats查transport lag与apply lag；v$managed_standby查mrp0的status；v$archive_dest_status查dest_id=2的status和error，覆盖data guard角色、同步状态、延迟及进程健康。

oracle data guard如何建立日常巡检与告警机制

日常巡检该查哪些视图和字段

核心不是“全查”，而是盯住 4 个关键视图的特定字段，覆盖角色、同步状态、延迟、进程健康。查多了反而漏重点。

必须在 CDB 层执行（哪怕你用的是多租户）：

v$database：只看 database_role 和 open_mode。主库必须是 PRIMARY + READ WRITE；ADG 备库必须是 PHYSICAL STANDBY + READ ONLY WITH APPLY
v$dataguard_stats：只过滤 name IN ('transport lag', 'apply lag')。值为 UNKNOWN 表示日志传输或应用已中断，不是“还没来得及计算”
v$managed_standby：只关注 process = 'MRP0' 的 status。正常是 APPLYING_LOG；WAIT_FOR_GAP 或 WAIT_FOR_LOG 都是明确故障信号
v$archive_dest_status：只查 dest_id = 2（即主库指向备库的归档目标）。status = 'ERROR' 或 error 字段非空（如 ORA-12170）直接判定传输失败

如何用 SQL 脚本自动化巡检

别写复杂脚本，一个可定时执行的 SQL 就够。关键是把异常状态显式标出来，而不是靠人肉扫表。

示例（保存为 dg_check.sql）：

SET PAGESIZE 0 FEEDBACK OFF VERIFY OFF
SELECT 'ROLE MISMATCH: ' || db_unique_name || ' is ' || database_role || '/' || open_mode
FROM v$database
WHERE (database_role = 'PRIMARY' AND open_mode != 'READ WRITE')
   OR (database_role = 'PHYSICAL STANDBY' AND open_mode NOT IN ('READ ONLY', 'READ ONLY WITH APPLY'));
<p>SELECT 'TRANSPORT LAG > 5min: ' || value || ' sec'
FROM v$dataguard_stats
WHERE name = 'transport lag' AND value != 'UNKNOWN' AND TO_NUMBER(REPLACE(value, ' days ', '*86400+')) > 300;</p><p>SELECT 'MRP0 NOT APPLYING: ' || status
FROM v$managed_standby
WHERE process = 'MRP0' AND status != 'APPLYING_LOG';</p><p>SELECT 'DEST_2 ERROR: ' || error
FROM v$archive_dest_status
WHERE dest_id = 2 AND (status = 'ERROR' OR TRIM(error) IS NOT NULL);</p><p>EXIT SQL.SQLCODE</p>

这个脚本返回非空行即告警。配合 sqlplus -s / as sysdba @dg_check.sql > /tmp/dg_alert.log 定时跑，再用 shell 判断文件是否为空即可触发邮件或钉钉通知。

Market Oracle

金融事件影响分析器 — 获取突发新闻，追踪金属/石油/加密货币/股票价格，预测短中长期市场连锁反应

下载

告警阈值设多少才不过度打扰

阈值不是拍脑袋定的，要匹配业务容忍度和网络现实：

transport lag 和 apply lag：生产环境建议 ≤ 120 秒（2 分钟），不是教科书写的 5 分钟。超过 2 分钟就该人工介入，因为 ADG 查询分流可能读到明显过期数据
v$archived_log 中 applied = 'NO' 的积压量：单线程备库允许最多 3 个归档未应用；RAC 主库配 RAC 备库可放宽到 10 个。超过就查 MRP0 是否卡住
Timer 等待事件占比：AWR 中 Timer 占比 > 8% 就要查（不是等它到 10%）。结合 v$session 看是不是集中在 MRP0 或 LNS 进程，再查网络或 I/O

注意：apply lag 显示 UNKNOWN 比显示一个大数字更危险——说明日志应用进程已停止，不是慢，是死了。

为什么 PDB 层验证不能省略

CDB 层一切看起来正常，但业务可能已经断连。这是最常被跳过的一步，也是故障复盘时最高频的盲点。

操作很简单，在任一业务 PDB 内执行：

建一张临时表：CREATE TABLE dg_test AS SELECT SYSDATE d FROM DUAL;
插入一行：INSERT INTO dg_test VALUES (SYSDATE); COMMIT;
立刻切到备库，连同一 PDB，查：SELECT * FROM dg_test;

如果查不到刚插的那行，或者报 ORA-01219（数据库未打开），说明 PDB 级同步断裂。常见原因是 PDB 没在备库上 ALTER PLUGGABLE DATABASE ... OPEN READ ONLY，或者 STANDBY_FILE_MANAGEMENT 参数没设为 AUTO 导致新增 PDB 文件不同步。