1

Data Guard介绍：

Data Guard 配置由一个产品数据库和一个或多个standby数据库组成。

DG配置中包含的那个产品数据库，也称作主数据库，作为primary角色，供大部分的应用来访问。主库可以是单实例数据库或RAC。

Standby数据库可以使用主库的备份拷贝来创建，并配置到DG中。DG通过传送和应用主库中的redo来自动维护standby数据库。和主库一样，standby数据库也可以是单实例或RAC数据库。Standby类型有物理 physical standby、逻辑 logical standby 、快照snapshot standby。

Data Guard 主要包含三种服务：Redo传输服务、应用服务和角色切换。

Redo传输主要的任务有：在主备系统之间传输redo数据、对由于网络问题造成的归档日志gap的解析过程进行管理、当检测到standby上的归档日志文件缺失或损坏时自动从主库或另一个standby数据库上检索对应的归档日志文件来进行替换。

在redo传输到standby数据库上以后，应用服务自动应用这些redo数据来与主库进行同步。

在Data Gurad环境中，至少有两个数据库，一个处于Open状态对外提供服务，这个数据库叫作Primary Database。第二个处于恢复状态，叫作Standby Database。

运行时primary Database对外提供服务，用户在Primary Database上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database。

这个日志会在Standby Database上重演，从而实现Primary Database和Standby Database的数据同步。

2

Oracle data guard的架构

1

日志发送（Redo Send)

1

日志发送（Redo Send）

Primary Database运行过程中，会源源不断地产生Redo日志，这些日志需要发送到Standy Database。

这个发送动作可以由Primary Database的LGWR或者ARCn进程完成，不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。选择哪个进程对数据保护能力和系统可用性有很大区别。

2

使用ARCn进程

1）Primary Database不断产生Redo Log，这些日志被LGWR进程写到联机日志。

2）当一组联机日志被写满后，会发生日志切换（Log Switch），并且会触发本地归档。

3）完成本地归档后，联机日志就可以被覆盖重用。

4）ARCn进程通过Net把归档日志发送给Standby Database的RFS（Remote File Server）进程。

5）Standby Database端的RFS进程把接收的日志写入到归档日志。

6）Standby Database端的MRP(Managed Recovery Process)进程（Redo Apply）或者LSP进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据。

用ARCn模式传输不写Standby Redologs，直接保存成归档文件存放于Standby端。

说明：

逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply。

2

日志接收(Redo Receive)

物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫Redo Apply。

注意：创建逻辑Standby数据库要先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。

使用ARCn进程传递最大问题在于：Primary Database只有在发生归档时才会发送日志到Standby Database。如果Primary Database异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCn进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分SYNC（同步）和ASYNC（异步）两种方式。

在缺省方式下，Primary Database使用的是ARCn进程，参数设置如下：

alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

1.	使用LGWR进程的SYNC方式
1）	Primary Database产生的Redo日志要同时写到日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
2）	LGWR必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database上的事务才能提交，这也是SYNC的含义所在。
3）	Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
4）	Primary Database的日志切换也会触发Standby Database上的日志切换，即Standby Database对Standby Redo Log的归档，然后触发Standby Database的MRP或者LSP进程恢复归档日志。
2.	使用LGWR进程的ASYNC方式使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。
1）	Primary Database一旦产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
2）	LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。
3）	Primary Database的Online Redo Log写满后发生Log Switch，触发归档操作，也触发Standby Database对Standby Redo Log的归档；然后触发MRP或者LSP进程恢复归档日志。

3

日志应用(Redo Apply)

	日志应用服务，就是在Standby Database上重演Primary Database日志，从而实现两个数据库的数据同步。根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby）和逻辑Standby（Logical Standby）。
	Physical Standby使用的是Media Recovery技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。Physical Standby数据库只能在Mount状态下进行恢复，也可以是打开，但只能以只读方式打开，并且打开时不能执行恢复操作。
	Logical Standby使用的是Logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句。Logical Standby数据库可以在恢复的同时进行读写操作。
	Standby数据库的相关进程读取接收到的REDO数据（可能来自于Standby端的归档文件，也可能来自于Standby Redologs），再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用
	根据Redo Apply发生的时间可以分成两种：一种是实时应用（Real-Time Apply），这种方式必须Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。另一种是归档时应用，这种方式在Primary Database发生日志切换，触发Standby Database归档操作，归档完成后触发恢复。这也是默认的恢复方式。

3

上面是主库到物理standby数据库的日志传输应用的一个流程图。

逻辑standby数据库不一样的地方是，使用SQL Apply代替Redo Apply，并且可以以read-write方式打开。

角色切换包含switchover和failover。

switchover主要用在主库的计划停机维护中，不会有数据丢失。

当主库不可用时，使用failover进行故障切换，数据是否可能丢失和选择的数据保护模式有关。

ITPub博客

Data Guard介绍

最新文章