带你玩转“数据卫士”Data Guard

来源：互联网发布：ubuntu 设置ntp客户端编辑：程序博客网时间：2024/05/29 18:19

1DG 的概念介绍

关于 DG，是 Oracle 自9i以来自带的数据同步功能，基本原理是将日志文件从原数据库传输到目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用性方案。

它通过建立一个 PRIMARY 和 STANDBY 组来确立其参照关系，如下图：

primary 数据库即被大部分应用访问的生产数据库，该库既可以是单实例数据库，也可以是 RAC；

Standby 数据库是 primary 数据库基于事物一致的复制库。Data Guard 通过应用 primary 数据库的 redo 自动维护 standby 数据库。Standby 数据库同样即可以是单实例数据库，也可以是 RAC 结构。

而 Standby 数据库又分为物理 Standby 和逻辑 Standby 两种，两者的同步方式不一样，逻辑 standby 是通过接收 primary 数据库的 redo log 并转换成sql语句，然后在 standby 数据库上执行 SQL 语句 (SQL Apply) 实现同步，而物理 standby 是通过接收并应用 primary 数据库的 redo log 以介质恢复的方式 (Redo Apply) 实现同步。

而针对数据的保护模式，可以在 V$DATABASE 中查看到 Data Guard 的保护模式：

下面通过一个表格简单的列出不同版本的 data guard 新特性：

注：新的备用数据库类型 “Far Sync Standby Database”

这是一个本地 ARCHIVELOG 仓库（靠近主（Primary）数据库），它可以将 Redo 信息发送到远端（很远距离）备用数据库。Far Sync Standby Database 是通过 Far Sync Standby 级联到主数据库的一个备用数据库。因此，它可以使用更高的保护模式来服务于远程备用数据库，即使网络没有完全表现其能力。所有到远程物理备用数据库的 Redo 传输是通过 Far Sync Standby Instance 完成。

说了那么多 data guard 的概念性的东西，那么 DG 有什么优势呢?

而我们搭建 DG 的时候又有那些安装条件呢？

1. 主备库数据库版本相同
2. 主库开启归档模式
3. 主备库不能跨平台，不过可以跨操作系统版本
4. 主备库字节序一致
5. 主备库目录可以不同、硬件资源配置可以不同
6. 主备网络无延迟
7. 备库存储空间建议大于主库

2如何搭建 DG

前面我简单的介绍了 DG 的一些概念，下面我们就来动手搭建一套简单的 DG 吧！

第一步：资源准备

1. 准备同主库相同操作系统平台的备机服务器，容量不能低于主库
2. 主库生成 standby controlfile
alter database create standby controlfile as '/***/control01.ctl';

第二歩：环境安装

1. 根据原库的 Oracle 版本和补丁号，对 DG 备机进行 Oracle 软件的安装和补丁升级，并配置好环境变量
2. 同步主库的 spfile、standby controlfile、orapw 文件放到备机相应位置注意 onctrolfile 的名字和路径需要和 spfile 中标记的一致
3. 启动主库到 mount 阶段

第三歩：主库设置检查、配置 DG 参数

-- 检查 force logging 是否开启为 YES
select force_logging from v$database;
-- 检查归档模式是否开启 ARCHIVELOG
select log_mode from v$database;
-- 配置 DG 参数
alter system set log_archive_dest_2='service=<sid>_sec LGWR SYNC NOAFFIRM NET_TIMEOUT=30';
-- 配置此归档路径先设置为 defer，等 standby 配置完后再设为 enablealter system set log_archive_dest_state_2=defer;
-- FAL 指获取归档日志的 server 端
alter system set fal_server='<sid>_sec';
-- FAL 指获取归档日志的 client 端
alter system set fal_client='<sid>';
注：这两个参数只需在 standby 库设置，但也可以在 primary 库设置这两个参数，以方便 switchover 或 failover 时 primary 库转变为 standby 角色
-- 打开数据文件自动添加
alter system set standby_file_management=auto;
-- 主库1800秒内自动切换 redo log
alter system set archive_lag_target=1800;

第四歩：配置 TNS

#主库
<sid> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = *))
)
(CONNECT_DATA =
(SERVICE_NAME = <sid>)
)
)

#备库
<sid>_sec =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))
)
(CONNECT_DATA =
(SERVICE_NAME = <sid>)
)
)

第五歩：备库参数配置

--#根据备机实际路径修改
alter system set log_archive_dest_1='location=/<sid>/db_dg_arc ';
alter system set fal_server='<sid>';
alter system set fal_client='<sid>_sec';

第六歩：备份主库

run{
allocate channel ch1 type disk;
allocate channel ch2 type disk;
backup database
format 'd:\oraclebackup\data_%T_%u_%c.bak';
backup archivelog all
format 'd:\oraclebackup\data_%T_%u_%c.arc';
backup current controlfile
format 'd:\oraclebackup\data_%T_%u_%c.ctl';
release channel ch1;
release channel ch2;
}

第七步：恢复备库

-- 可使用最新的 standby control file 作为控制文件恢复数据文件
alter database mount;
restore database;
restore archivelog all;
select max(sequence#) from v$archived_log;
recover databaese;

第八步：配置 listener.ora 和 tnsnames.ora 并启动监听

# listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = <sid>)
(ORACLE_HOME = /u01/oracle/product/db11gr2)
(SID_NAME = <sid>)
)
)

LISTENER =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))
)

ADR_BASE_LISTENER = /u01/oracle
#TNS
#主库
<sid> =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.1)(PORT = *))
)
(CONNECT_DATA =
(SERVICE_NAME = <sid>)
)
)

#备库
<sid>_sec =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.0.2)(PORT = *))
)
(CONNECT_DATA =
(SERVICE_NAME = <sid>)
)
)

第九歩：备机启动到 standby mount 阶段

Shutdown immediate
startup nomount;
alter database mount standby database;

第十步：备机上创建 standby logfile

ALTER DATABASE ADD STANDBY LOGFILE group 4 ('/*/stdredo01.log') SIZE **;
ALTER DATABASE ADD STANDBY LOGFILE group 5 ('/*/stdredo02.log') SIZE **;
ALTER DATABASE ADD STANDBY LOGFILE group 6 ('/*/stdredo03.log') SIZE **;

………………
注：standby logfile 需要比 redologfile 多一组，每组只能创建一个成员，group 编号不能重复

第十一歩：主库开启 log_archive_dest_state_2参数

alter system set log_archive_dest_state_2=enable;
#启动日志传输

第十二歩：DG 备库上启动同步

#开启应用
alter database recover managed standby database disconnect from session;
#并行开启应用
alter database recover managed standby database parallel 4 disconnect from session;

这样一套简单的 DG 库就搭建完毕了。

那么问题来了，咱们如何知道咱们的 DG 库日志同步正常、redo日志应用没问题呢？

3如何监控 DG

一般 DG 安装完之后，或者在运行中，我们都会通过一个重要的视图 v$managed_standby 监控各进程的状态，以及归档应用情况：

注：进程 process 对应的几种不同名称表示不同的 data guard 进程，其中 RFS 进程表示接收日志进程、MRP0 进程表示恢复进程、ARCH 表示 Archiver 进程，后面跟着的 STATUS 表示每个进程的状态，THREAD# 表示实例的进程号，每个状态的说明如下：

ALLOCATED: 正在准备但还未连接主库
ATTACHED: 正在连接到主库
CONNECTED: 已经连接到主库
IDLE: 空闲
ERROR: 失败的进程，需要关注
RECEIVING: 归档日志接收中
OPENING: 归档日志处理中
CLOSING: 归档日志处理完，正在收尾中
WRITING: 进程在将 REDO 数据写向归档文件中
WAIT_FOR_LOG: 等待新的 REDO 归档数据中
WAIT_FOR_GAP: 归档有中断，正在等待中断的那部分 REDO 数据.
APPLYING_LOG: 正在应用 REDO 归档数据到备库

那么从上图可以看出，我们的 DG 库正在应用实例进程为2的日志8850，通过 RFS 日志传输进程看出日志传输到了实例1的日志13413.

我们通过备库获取到的这些信息，可拿到主库去比对当前数据库的最大日志号是多少，就能知道当前 DG 库的日志应用、传输情况是否正常了。

当然查询的方法很多，例如也可以通过备库、主库的 ALERT 日志进行比对，或看备库日志是否有报错等都能对 DG 库进行监控。

在此，我们来抛出一个问题：假如您是对100套主备库进行 DG 日常管理，那么您该如何监控这100多套主备库的实时应用状态呢？

以上为我们自己在运维大量 DG 主从库中的实际监控经验分享，方法还多种多样，各位小伙伴可以集思广益，也分享给大家。

在运维过程中，DG 库的监控是不容忽视的一部分，因为这关乎着我们的数据是否跟生产保持正常的同步状态，那么假如遇到主库故障了，我们又该如何使用 data guard 库保证业务连续性呢？下面我们用图来说明一下主从 DG 的切换方式。

4DG 的切换方式

在 DataGuard 模式下，有两种切换模式，Switchover 和 Failover ，这两种切换都需要手工执行完成（通过执行 sql 命令或用 Data Guard broker interface 工具完成）。

Failover 方式的切换是在主数据库宕掉（一般是硬件严重故障导致）后，物理备用数据库切换成 primary role 如图：

Switchover 方式是 primary 和 standby 互换角色，一般都是人为的有计划的切换，不会造成数据丢失。如图：

Data Guard broker interface 属于故障自动切换，因涉及生产数据的一致性，不建议配置。

接下来，我为大家分享一下 DG 的日常运维。

5DG 日常运维

1. 停止 Standby

-- 查看备库是否在应用日志进行恢复
select process, status from v$managed_standby;
alter database recover managed standby database cancel;
shutdown immediate;

2. 切换到只读模式

-- 由 shutdown 模式切换到只读模式
startup nomount;
alter database mount standby database;
alter database open read only;
-- 由应用日志模式切换到只读模式
-- 取消日志应用
alter database recover managed standby database cancel;
alter database open read only;
-- 物理 Standby 取消延迟应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;

3. 切换回管理恢复模式

-- 启动日志应用
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;
alter database recover managed standby database using current logfile disconnect from session;
-- 备库延迟120分钟应用主库日志
alter database recover managed standby database delay 120 disconnect from session;

4. 主库和备库之间角色切换

-- 主库切换为备库
alter database commit to switchover to physical standby;
-- 主库有会话连接的时候
alter database commit to switchover to physical standby with session shutdown;
shutdown immediate
startup nomount;
alter database mount standby database;
alter database recover managed standby database disconnect from session;

-- 从库切换为主库
alter database commit to switchover to primary;
shutdown immediate;
startup
alter system switch logfile;

5. 备库自动使用主库传过来的日志进行恢复

alter database recover automatic standby database;

6. 更改保护模式

alter database set standby database to maximize protection;
alter database set standby database to maximize availability;
alter database set standby database to maximize performancen;

7. 取消自动恢复模式

alter database recover managed standby database cancel;
alter database recover managed standby database finish;
alter database recover managed standby database finish force;

8. 查看主备库保护模式

-- 查看主库保护模式：
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL OPEN_MODE
-------------------- ---------------- -------------------- --------------------
MAXIMUM PERFORMANCE PRIMARY MAXIMUM PERFORMANCE READ WRITE
-- 查看备库保护模式：
SQL> select protection_mode,database_role,protection_level,open_mode from v$database;
PROTECTION_MODE DATABASE_ROLE PROTECTION_LEVEL OPEN_MODE
-------------------- ---------------- -------------------- --------------------
MAXIMUM PERFORMANCE PHYSICAL STANDBY MAXIMUM PERFORMANCE MOUNTED

9. 查看备库进程状态

SQL>select process,client_process,sequence#,status from v$managed_standby
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ----------
ARCH ARCH 153 CLOSING
ARCH ARCH 154 CLOSING
MRP0 N/A 158 WAIT_FOR_LOG
RFS UNKNOWN 0 IDLE
RFS LGWR 158 IDLE
RFS ARCH 0 IDLE

10. 主库建立备库的 standby 控制文件

SQL> alter database create standby controlfile as '/u01/standby.ctl' reuse;

11. 查询 GAP

select * from V$ARCHIVE_GAP;

12. 注册日志

ALTER DATABASE REGISTER LOGFILE '日志';

6DG 的实用技巧

在 DG 的日常应用中，我们能从中得到很多便利，今天最后给大家分享一二，抛砖引玉。

1. 在 Oracle 11g 之前，物理备库（physical Standby）在应用 redo 的时候，是不可以打开的，只可以 mount。从 11g 开始，在应用 redo 的时候，物理备库可以处于 read-only 模式，这就称为 Active Data Guard 。通过 Active Data Guard，可以在物理备库进行查询或者导出数据，从而减少对主库的访问和压力, Active Data Guard 适用于一些只读性的应用，比如，有的应用程序只是查询数据，进行一些报表业务，不会产生 redo 数据，这些应用可以转移到备库上，避免对主库资源的争用，一些实时性要求不高的查询应用也可以部署数据源指向 ACTIVE DG 达到读写分离的效果。

如下图读写分离的典型架构 -Reader Farm 对网站应用。

2. Oracle10G 引入闪回，启用 flashback database 后数据库可以在备库闪回某些误删除操作，且每次闪回开启不用重新搭建备库、且可以把有些生产变更的风险操作在 DG 备可以上提前当做预生产执行，验证生产变更的可靠性。

3. 备份、迁移、生产数据导出均可以在 DG 备库上执行

4. 定期进行容灾演练保障容灾系统的可用性

总结

当然还有很多 DG 的妙用等待各位小伙伴们来我们恩墨大讲坛进行分享，回过头来，各位亲是不是就对今天分享一开始上的那张霸气十足的图有一个深入的认识了呢？其实那种跨越2000多公里距离的 DG 应用就是一个两地三中心的建设模型图，偶们现在是不是也可以轻松搞定了呢？