Oracle DG/ADG架构巡检与高可用实践-平芜编程栈

1. Oracle DG/ADG架构核心价值解析

在金融、电信等关键行业的生产环境中，数据库高可用性直接关系到业务连续性。Oracle Data Guard（DG）及其高级模式Active Data Guard（ADG）作为Oracle官方提供的灾备解决方案，通过主备库架构实现数据冗余保护。与第三方工具相比，DG/ADG的优势在于与Oracle数据库内核深度集成，在保证RPO=0的同时，ADG还能实现备库只读开放，有效分担主库负载。

我管理过的某省级医保系统采用ADG架构后，不仅将RTO控制在15分钟以内，还利用备库处理了30%的报表查询请求。这种架构的稳定运行离不开系统化的巡检机制，接下来将分享经过实战验证的巡检方案。

2. 基础环境健康检查

2.1 网络与存储状态验证

首先通过操作系统层面命令检查基础资源：

# 检查网络延迟（主备库之间执行） ping -c 5 standby_db_ip | grep rtt # 检查ASM磁盘组剩余空间 asmcmd lsdg --suppressheader

理想情况下网络延迟应<2ms，ASM磁盘组使用率不超过80%。曾遇到某次故障因存储未设置自动扩展导致归档日志写入失败，因此建议在巡检时特别注意归档目录空间：

-- 检查归档日志存放位置 SELECT DEST_NAME, STATUS, DESTINATION FROM V$ARCHIVE_DEST WHERE STATUS='VALID';

2.3 数据库进程状态确认

通过以下命令检查关键进程：

-- DG专属进程状态 SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE PROCESS LIKE 'MRP%' OR PROCESS='RFS';

正常状态下应存在MRP（Managed Recovery Process）和RFS（Remote File Server）进程。某次生产故障就是因为RFS进程异常导致归档传输中断，后来我们在巡检清单中增加了进程状态检查项。

3. 数据同步状态深度检测

3.1 同步延迟量化分析

通过以下视图获取精确的延迟数据：

-- 计算备库延迟时间（分钟） SELECT (SYSDATE - DATUM_TIME) * 1440 AS delay_minutes, SEQUENCE# AS current_seq FROM V$DATAGUARD_STATS WHERE NAME='apply lag';

在OLTP系统中，延迟超过5分钟就需要立即干预。我们曾通过该指标发现某次网络抖动导致的同步异常，及时切换备用链路避免了数据丢失。

3.2 归档日志连续性检查

使用以下SQL验证日志传输完整性：

-- 检查缺失的归档序列 SELECT THREAD#, MIN(SEQUENCE#) AS min_seq, MAX(SEQUENCE#) AS max_seq, COUNT(*) AS actual_count, MAX(SEQUENCE#) - MIN(SEQUENCE#) + 1 AS expected_count FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND APPLIED='YES' GROUP BY THREAD#;

如果actual_count小于expected_count，说明存在日志缺失。某次存储故障就导致序列号12345-12347的日志丢失，我们通过RMAN的增量备份完成了补全。

4. ADG特有功能验证

4.1 实时查询能力测试

在ADG备库执行：

-- 验证打开模式 SELECT OPEN_MODE, DATABASE_ROLE, PROTECTION_MODE FROM V$DATABASE; -- 执行测试查询 SELECT /*+ MONITOR */ COUNT(*) FROM large_table WHERE create_date>SYSDATE-30;

OPEN_MODE应为READ ONLY WITH APPLY。某客户曾抱怨查询性能差，后来发现是备库未启用实时应用（Real-Time Apply），导致数据延迟高达2小时。

4.2 自动修复功能验证

模拟块损坏测试自动修复：

-- 在主库制造坏块（谨慎操作！） ALTER SYSTEM SET DB_LOST_WRITE_PROTECT=TYPICAL; -- 检查备库自动修复记录 SELECT * FROM V$DATAGUARD_AUTOMATIC_REPAIR;

该功能需要开启DB_LOST_WRITE_PROTECT参数。在巡检时建议记录自动修复事件，分析潜在存储问题。

5. 性能与资源监控

5.1 传输与应用速率统计

-- 获取最近1小时传输统计 SELECT * FROM V$DATAGUARD_TRANSPORT_STATS WHERE NAME IN ('transport lag', 'network latency') AND TIME_COMPUTED > SYSDATE-1/24;

健康状态下传输延迟应呈平稳曲线。某次性能下降就是通过该视图发现网络带宽被其他应用占用。

5.2 资源使用TOP SQL分析

在ADG备库执行：

-- 找出高负载查询 SELECT SQL_ID, ELAPSED_TIME/1000000 AS sec, MODULE FROM V$SQLAREA WHERE ROWNUM<=10 ORDER BY ELAPSED_TIME DESC;

曾通过该查询发现某报表SQL未使用绑定变量，导致备库内存耗尽。

6. 容灾切换演练方案

6.1 计划内切换检查清单

确认无活动事务：
```
SELECT COUNT(*) FROM V$TRANSACTION;
```

冻结备库应用：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

执行角色转换：

-- 在主库执行 ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY;

6.2 故障切换应急步骤

确认主库不可用：
```
tnsping primary_db:1521
```

激活备库：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH; ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

某次数据中心断电时，我们通过该流程在8分钟内完成了业务恢复。

7. 巡检报告自动化生成

推荐使用Shell脚本整合关键检查项：

#!/bin/bash # 生成HTML格式报告 sqlplus -s / as sysdba <<EOF | tee dg_check_$(date +%Y%m%d).html SET MARKUP HTML ON @dg_check.sql EOF

示例检查脚本dg_check.sql应包含前文所有关键SQL。我们团队将该脚本与Zabbix集成，实现了7×24小时监控。

8. 典型故障处理实录

8.1 归档日志堆积

现象：备库延迟持续增长解决方案：

-- 增加应用进程数 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING 4 PROCESSES; -- 调整批量应用大小 ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;

8.2 ORA-16191错误

错误原因：主库未传输必要的日志处理方法：

-- 在主库注册备库 ALTER SYSTEM ARCHIVE LOG CURRENT FOR STANDBY; -- 在备库重新注册 ALTER DATABASE REGISTER PHYSICAL LOGFILE '/path/to/logfile';

在每月例行维护中，建议额外检查DG_BROKER配置：

SHOW CONFIGURATION; VALIDATE CONFIGURATION;

这个简单操作曾帮助我们提前发现过3次配置漂移问题。

Oracle DG/ADG架构巡检与高可用实践