Oracle Dataguard（主库为 Oracle 11g 单节点）配置详解（1）：Oracle Dataguard 工作原理

Oracle Dataguard 是保证企业数据的高可用性（high availability，HA）、数据保护（data protection）与灾难恢复（disaster recovery）的集成化灾难恢复解决方案。

Oracle Dataguard 针对生产数据库创建一个或多个同步备份，由一个生产数据库和若干个备用数据库组成，形成一个独立的、易于管理的数据保护方案。

一、Oracle Dataguard 工作过程

1、当某次事务更改主库中的数据时，Oracle 在联机重做日志文件（redo log）中记录此次更改。Oracle Dataguard使用日志写入器进程（LGWR）或归档器进程（ARCH）收集重做日志信息。

2、主库除了把日志记录到本地的联机日志文件和归档日志文件中，还通过网络，把日志信息发送到远程的备库服务器。

备用日志文件写入过程可以实时同步（SYNC，最大保护模式），以实现零数据丢失。也可以是异步（ASYNC，最大可用性模式）的，以减少对网络带宽的压力。或者通过归档日志文件的批量传输模式（最大性能模式），以减少对生产系统的性能影响。

3、在备库上，Oracle Dataguard使用远程文件服务器（RFS）进程从主库接收重做日志（redo log）信息，使用管理恢复进程 （MRP）将重做日志信息应用到物理备库中。使用逻辑备用进程（LSP）将经过SQL转换的重做日志信息应用到逻辑备库中。

4、当主库打开并处于活动状态时，备库可以执行恢复操作。如果主数据出现了故障，备库即可以被激活并接管主库的工作。

下图为一个Oracle Dataguard的模型。

上图中，主库在运行时会不断产生redo log，这些日志会通过网络传送到备库，这个传送动作，可以由ARCH完成，也可以由LGWR完成，选用哪种进程，对数据库的可用性和DG的保护能力有着很大的区别。

二、Oracle Dataguard 日志传送方式

1、使用 ARCH 进程传送日志

主库不断的产生redo log，这些日志被LGWR写进联机日志，当一组联机日志被写满，会发生日志切换，并且ARCH会将其归档，ARCH进程还会通过网络把归档日志传送给备库的一个叫做RFS的进程，备库接受日志并写入到归档日志，然后备库的MRP进程（redo apply）或者LSP进程（SQL apply）在备库上应用这些日志，于是数据就同步了。

默认情况下，主库使用ARCH进程传送日志，不需要特别的设置。

2、使用LGWR进程传送日志

LGWR又分为SYNC（同步）和ASYNC（异步）两种方式：

（1）使用 LGWR 进程的 SYNC 方式

主库产生redo log要同时写入到日志文件和网络，即LGWR把日志写到本地联机日志文件的同时，还发送给本地的LNSN进程（Network Server Process），然后LNSN进程把日志内容通过网络发送到备库。

LGWR必须等待写入本地联机日志和LNSN进程传送成功，主库的事务才能提交，这就是实时同步的原理。

备库的RFS进程把接收到的日志立刻写入standby redo log中。

备库的恢复方式可以是实时恢复，也可以是完成对standby redo log的归档后恢复。

NET_TIMEOUT参数单位为秒，作用是该段时间网络无响应，LGWR会抛出错误。

LOG_ARCHIVE_DEST_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30'

（2）使用 LGWR 进程的 ASYNC 方式

使用LGWR SYNC方式也有弱点，如果在发送给standby db过程中出错，LGWR会报错，主库事务无法完成，主库LGWR过分依赖网络状态。

LGWR ASYNC方式的工作过程如下：

主库产生redo log之后，LGWR进程把日志写到本地联机日志文件的同时，发送给本地的LNSN进程，和LGWR SYNC方式相比，LGWR只需要成功写入日志文件，事务即可提交，不必等待LNSN进程传送成功。

主库联机日志写满后归档，也会触发备库的standby redo log归档，然后触发MRP或LSP进程恢复归档。

由于LSWR不会等待LNSN，所以无需配置NET_TIMEOUT参数。

三、standby redo log 的作用分析

standby redo log（SRL），和传统的online redo log（ORL）相比，有以下特点：

1、SRL和ORL两种文件是完全相同的，只是两者发挥的作用和场景不同。

2、SRL只在备库上起作用（虽然主库也可以配置SRL），当数据库处于主库角色时，SRL是不活动的，只有经过了角色切换，变成了备库角色时，SRL日志才会变成活动的。

3、对于处于备库角色的数据库来说，ORL不是必须的，也不会起作用，只有当角色切换，变成主库角色时，ORL文件才起作用。

4、对于处于备库角色的数据库来说，从主库接收到的日志可以记录在SRL文件中，也可以记录在归档日志文件中，具体写在哪个文件中取决于具体配置，但是不会写在ORL中。

5、SRL必须和ORL大小完全一致，否则SRL也不会被用到。其次，从数量上，应该按照每个实例或日志线程N+1的数量关系来配置，例如2个实例的RAC，如果每个实例3组日志，则SRL应该是(3+1)*2=8组。

5、是否使用SRL，关键区别在于RFS把接收到的日志，是写在归档日志里，还是写在SRL里。

四、Oracle Dataguard 日志接收过程

备库的RFS进程接收到日志后，把日志写到standby redo log或者archived log file文件中。

归档日志的位置取决于standby database归档路径的选择：

1、如果配置了standby_archive_dest，则使用这个参数指定的目录；

2、如果配置了log_archive_dest_n，该参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)，则使用这个参数指定的目录；

3、如果standby_archive_dest和log_archive_dest_n参数都没有配置，使用缺省的standby_archive_dest参数，这个缺省值是$Oracle_HOME/dbs/arch。

五、Oracle Dataguard 日志应用过程

日志应用就是在备库上重演主库的日志，从而实现两个数据库的数据同步。

Oracle Dataguard 将主库的redo log传输给备库，然后将redo log数据应用到备库，从而实现两个数据库的数据同步。

Oracle Dataguard提供两种方法将redo log数据应用到备库，这两种方法与Oracle Dataguard支持的两种类型的备库对应：

1、物理备库（重做应用）：使用media recovery技术，在数据块级别进行恢复。这种方式没有数据类型的限制，可以保证两个数据库完全一致。

2、逻辑备库（SQL apply）：使用logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句。

就从主库进行的数据传输而言，这两种类型的备库之间没有差别。一旦redo log数据到达备库，这两种类型的备库在将redo log数据应用到备库的方式上就存在差异了。

根据日志应用发生的时间可以分为2种：

1、实时应用（Real-Time Apply）：这种方式必须有standby redo log，每当日志被写入standby redo log时，就会触发恢复。

实时应用使备库与主库保持密切同步，可以减少数据库切换的时间。

要启用物理备库的实时应用，在物理备库执行以下命令：

alter database recover managed standby database using current logfile disconnect;

要启用逻辑备库的实时应用，在逻辑备库执行以下命令：

alter database start logical standby apply immediate;

查看备库是否应用了实时应用：

SQL> select recovery_mode from v$archive_dest_status;RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY

2、归档时应用：这种方式在主库发生日志切换之后，才触发备库的归档，归档完成后再触发恢复，这也是默认的方式。

六、Oracle Dataguard 数据保护模式

Oracle Dataguard提供三种数据保护模式（最大保护、最高可用性、最高性能）来平衡成本、可用性、性能和事务保护。

下表从数据丢失风险的角度概述了各种模式的适用性。

保护模式	在出现灾难时数据丢失的风险	重做传输机制
最大保护	零数据丢失；双重故障保护	LGWR SYNC
最高可用性	零数据丢失；单故障保护	LGWR SYNC
最高性能	最小数据丢失——通常从 0 到几秒	LGWR ASYNC 或 ARCH

这三种模式的区别在于，当主库发生故障时，备库的数据会和主库有多大的差距。

1、最大保护模式：Maximum Protection

这是最高的数据保护级别，这个模式的规则是即便牺牲主库的可用性，也要保证不出现数据丢失。这个级别保证备库和主库的数据是完全同步的，即使主库突然宕机，在备库上也不会出现任何数据丢失。

最大保护模式要求备库必须配置SRL，主库必须使用LGWR、SYNC、AFFIRM方式归档到备库。

最大保护模式下，主库上的每个事务的redo log必须在和本地和备库上都写入日志文件后才允许提交。如果不能写入到备库，主库就会自动关闭以方式数据丢失，主库不再生成任何redo log，并且不断地尝试连接备库，这一段时间内LGWR不再生成任何redo log，整个数据库表现为挂起。

最大保护模式下，至少要有一个备库是正常的，主库才能正常打开，否则主库无法打开。

如果主库是RAC环境，如果一个实例和备库之间网络发生问题，那么在最大保护模式下，这个实例是crash，继而触发其他实例的crash recovery，完成recovery之后，Oracle Dataguard会忽略这个实例，而主库其他实例也能继续处理业务，并发送日志进行同步。除非所有实例连接备库都出现了问题，才会出现所有实例crash，最终导致整个数据库的crash。

2、最大可用模式：Maximum Availability

这是另外一种能实现零数据丢失的数据保护方案。这种模式需要至少有一个备库是通过SYNC和AFFIRM方式传送数据，并且要使用SRL文件才行。

在这种模式下，主库发送redo log、并等待备库确认，备库收到redo log，并记录到SRL中，并返回确认给主库，这时，主库上的事务才能结束。这是和最大保护模式一样的地方。

如果主库在该段时间（默认30秒）没有收到任何反馈信息，这个备库就会被标记成failed，LGWR会继续写日志，但是会忽略掉这个failed的备库。

一旦备库被认为是failed，那么主库就会强制进行一次日志切换，以明确的标识出发生failed的时间点，也就是达到零数据丢失的时间点，而在这以后产生的redo log就不再向备库发送了。

在RAC环境下，如果一个实例认为备库是failed，则自动触发的日志切换会导致所有的实例都停止发送redo log，即便其他实例能够连接到备库。

3、最大性能模式：Maximum Performance

最高性能模式是默认的保护模式。在此种模式下，主库上事务的redo log只要写到本地日志文件就可以提交，不必等待到备库传递完成。主库的redo log以异步发送到备库。备库的任何故障，以及两者之间的网络故障都不会影响主库的活动，即便网络出现问题，主库也只不过暂时停止redo log传送，并等待ARCH进程通过PING机制发现连接恢复之后，继续重传。

这种模式可以使用LGWR ASYNC或者ARCH实现，备库也不要求使用SRL。

如果主库是RAC，并且工作在最大性能模式下，如果只是RAC的某个实例和备库的日志传递发生故障，那么也只有该实例的日志传递被中止。而其他实例的日志传递仍然继续。发生中断的实例上的ARCH进程会不断地通过ping机制来检查连通性，一旦发现连接恢复，这个实例上的gap会自动发送给备库，但是LGWR进程却并不会立即启动LNS进程去发送当前的redo log数据，而是直到下一次日志切换时，LGWR才会启动LNS，开始传递redo log数据。

4、定义数据保护模式

保护模式是针对主库进行设置的，这个设置是告诉主库必须要遵守的规则。对备库没有作用。

数据保护模式在定义数据保护级别的同时，也同时定义了两个重要信息：

（1）主库如何向备库传送redo log。

（2）当备库发生故障或网络出现故障，主库应该怎么做。

在主库上执行下面的SQL语句可用于设置三种数据保护模式：

ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;    -- 最大保护
ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;  -- 最高可用性
ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;   -- 最高性能-- 修改数据保护模式：
alter database set standby to maximize availability;SQL> select protection_mode,protection_level from v$database;PROTECTION_MODE      PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY