Oracle DG / ADG日常巡检操作指南

一、Oracle DG / ADG 简介

1. 什么是 DG

DG，全称 Data Guard ，是 Oracle 提供的主备容灾方案。

它通过将主库产生的重做日志传输到备库，并在备库上持续应用日志，来保持主备数据同步。

DG 的核心作用主要有三点：

• 容灾保护：主库故障时，可切换到备库继续提供服务

• 数据同步：尽量保证备库数据与主库保持一致

• 高可用保障：降低单点故障带来的业务中断风险

简单理解：

DG = 给主库准备一个随时待命的备库。

---

2. 什么是 ADG

ADG，全称 Active Data Guard ，可以理解为 增强版的 Data Guard。

它和普通 DG 的区别在于：

普通 DG 的物理备库通常主要用于恢复和切换；
ADG 的物理备库在应用日志的同时，还可以对外提供只读访问。

也就是说，ADG 不只是"备着不用"，而是可以一边同步，一边查。

ADG 的主要特点：

• 备库实时接收并应用主库日志

• 备库可只读开放

• 可用于查询分流、报表查询、容灾备份

• 主库故障时，也可以作为切换目标

简单理解：

ADG = 不仅能备，还能查。

---

3. DG 和 ADG 的区别

对比项	DG	ADG
是否具备主备同步能力	是	是
是否用于容灾切换	是	是
备库是否可只读开放	一般不强调在线查询	是
备库是否可边应用边查询	不属于核心特点	是
典型用途	容灾、故障切换	容灾 + 查询分流

4. 一句话理解

你可以直接记这两个：

• DG：主备同步，主要用于容灾

• ADG：在 DG 基础上，备库还能只读查询

二、本文适用范围

先在 CDB 层查状态，再在 PDB 层做简单写入验证。

适用于以下环境：

• 单机 → 单机

• RAC → 单机

• RAC → RAC

---

三、巡检层级说明

1. 日常巡检以 CDB 层级 为主

以下检查命令均在 CDB 层级 执行：

• v$archive_dest

• v$dataguard_stats

• v$database

• v$managed_standby

2. 简单写入验证在 PDB 层级 执行

建表、插数、查询这部分，属于业务验证 ，应在某个业务 PDB 内执行。

每个 CDB 任选 一个 PDB 验证即可。

3. 结论

• 状态检查：查 CDB 层

• 同步验证：查 PDB 层

四、标准巡检步骤

1. 主库检查归档传输状态

层级：CDB

set line 200
col error for a30
col dest_name for a30

select dest_name,status,error,target,process
from v$archive_dest
where dest_name in ('LOG_ARCHIVE_DEST_1','LOG_ARCHIVE_DEST_2','LOG_ARCHIVE_DEST_3','LOG_ARCHIVE_DEST_4');

正常判断：

• 发往备库的目标为 STANDBY

• STATUS = VALID

• ERROR 为空

---

2. 备库检查同步延迟

层级：CDB

set linesize 200
select name,value,datum_time
from v$dataguard_stats
where name in ('transport lag','apply lag','apply finish time');

正常判断：

• transport lag 很小或为 +00 00:00:00

• apply lag 很小或为 +00 00:00:00

---

3. 备库检查角色和打开模式

层级：CDB

set linesize 200
col db_unique_name for a20
col database_role for a20
col open_mode for a25

select name,db_unique_name,database_role,open_mode
from v$database;

正常判断：

• DATABASE_ROLE = PHYSICAL STANDBY

• OPEN_MODE = READ ONLY WITH APPLY

---

4. 备库检查接收/应用进程

层级：CDB

set linesize 200
col process for a10
col status for a20

select process,status,thread#,sequence#
from v$managed_standby;

正常判断：

• 能看到 RFS

• 结合前面 2、3 步正常，可判断 ADG 状态基本正常

---

5. 主备网络连通检查

层级：操作系统层

tnsping 主库服务名
tnsping 备库服务名

正常判断：

• tnsping 返回正常

---

6. 简单写入验证（放最后）

层级：PDB

这一步作为你日常巡检的最终确认手段。

每个 CDB 任选一个业务 PDB 验证即可。

第一步：进入主库某个业务 PDB

例如：

export ORACLE_SID=HISCDB1;
sqlplus / as sysdba
show pdbs;
show con_name;
alter session set container=HISDB;
show con_name;

第二步：主库创建测试表并插入数据

CREATE TABLE ADGTEST (
id NUMBER PRIMARY KEY,
create_time DATE DEFAULT SYSDATE
);

INSERT INTO ADGTEST (id) VALUES (1);
COMMIT;

INSERT INTO ADGTEST (id) VALUES (2);
COMMIT;

INSERT INTO ADGTEST (id) VALUES (3);
COMMIT;

SELECT * FROM ADGTEST;

第三步：切到备库对应 PDB 查询

例如：

export ORACLE_SID=HISCDB1;
sqlplus / as sysdba
show pdbs;
show con_name;
alter session set container=HISDB;
show con_name;

然后查询：

SELECT * FROM ADGTEST;

正常判断：

• 主库插入成功

• 备库能查到相同数据

  说明该 PDB 对应数据同步正常，ADG 验证通过。

---

五、适用性说明

1. 单机 → 单机

适用。

2. RAC → 单机

适用。

RAC 主库任选一个实例执行 CDB 层检查；PDB 验证任选一个业务 PDB。

3. RAC → RAC

适用。

主备两端任选一个正常实例执行 CDB 层检查；PDB 验证同样任选一个业务 PDB。

在 RAC 环境中，v$managed_standby 里出现多个 thread#、多个 RFS 属于正常现象。

---

六、正常判定标准

满足以下条件，可判断 ADG 正常：

1. 主库发往备库的归档目标 STATUS = VALID

2. 主库归档目标 ERROR 为空

3. 备库 DATABASE_ROLE = PHYSICAL STANDBY

4. 备库 OPEN_MODE = READ ONLY WITH APPLY

5. transport lag 很小或为 0

6. apply lag 很小或为 0

7. 备库存在 RFS

8. 主备 tnsping 正常

9. 主库 PDB 插入测试数据后，备库对应 PDB 能查到相同数据