Oracle Data Guard（10g）原理解析

本篇文章来自于网络及《大话Oracle RAC》这本书，并对内容进行了综合梳理，本文只详细介绍Data Guard的深度原理，同时也是自己的学习心得，不涉及如何搭建Data Guard和参数设置，内容有些枯燥，但基础知识一定要掌握而且要牢固，就像习武一样，步步为营，稳扎稳打，才能达到巅峰。

一、什么是Data Guard？

Data Guard，故名思议，数据卫士！是通过冗余数据来提供数据保护，其实现的机制是通过日志同步保证冗余数据和主数据之间的同步，这种同步可以是实时、延时、同步、异步等多种形式的。Data Guard常用于异地容灾和小企业的高可用性方案。在Data Guard环境中，至少会有两个数据库，一个处于Open状态，对外提供服务，叫作Primary Database。另一个处于恢复状态，叫作Standby Database。运行时Primary Database对外提供服务，应用程序在Primary Database上进行操作，操作记录被记录在联机日志和归档日志中，这些日志通过网络传递给Standby Database并进行重演，从而实现Primary Database和Standby Database的数据同步。

Oracle官方文档对Data Guard的概念如下：

Oracle Data Guard ensures high availability, data protection, and disaster recovery for enterprise data. Data Guard provides a comprehensive set of services that create, maintain, manage, and monitor one or more standby databases to enable production Oracle database to survive disasters and data corruptions. Data Guard maintains these standby databases as copies of the production database. Then, if the production database becomes unavailable because of a planned or an unplanned outage, Data Guard can switch any standby database to the production role, minimizing the downtime associated with the outage. Data Guard can be used with traditional backup, restoration, and cluster techniques to provide a high level of data protection and data availability.With Data Guard, administrators can optionally improve production database performance by offloading resource-intensive backup and reporting operations to standby systems.

以上内容翻译如下：

Oracle Data Guard确保企业数据的高可用性，数据保护和灾难恢复。Data Guard提供了一套全面的服务，可以创建，维护，管理和监视一个或多个备用数据库，从而实现Oracle的生产数据库以应对灾难和数据损坏。Data Guard将这些备用数据库维护为生产数据库的副本。然后，如果生产数据库由于计划中断或计划外中断而变得不可用，则Data Guard可以将任何备用数据库切换到生产角色，从而最大限度地减少与停机相关的停机时间。Data Guard可以与传统备份，恢复和群集技术一起使用，以提供高级别的数据保护和数据可用性。借助Data Guard，管理员可以选择通过将资源密集型备份和报告操作卸载到备用系统来提高生产数据库性能。

典型的Data Guard配置

二、Data Guard的三大服务

Data Guard原理主要围绕着以下三大服务，这三大服务是Data Guard的核心，如果把它们理解透彻、研究透了，那么Data Guard的原理也就差不多都掌握了。在此之前我们先了解Data Guard环境中两端的重要进程。

Primary Database：

LGWR：在Primary Database上，这个进程负责把Redo Buffer中的内容写入到联机日志文件中。

LNS（Log Network Service）：LNS进程读取日志，并通过网络发送给Standby Database，这个进程的目的是为了减轻LGWR的负担，在Oracle11g中，LGWR进程不用再参与到网络日志传递中了。

ARCH：归档进程，在Primary Database中可以有30个归档进程，其中有一个是专门负责本地归档的，其他的ARCH进程都可以向Standby Database传送日志。

Standby Database：

RFS（Remote File Server）：这个进程负责接收网络上传送过来的Redo日志，并把这些日志写到Standby Redo Log（SRL）文件中。

ARCH进程：同样是归档进程，只是在Standby上，需要归档的是SRL日志文件。

MRP（Managed Recovery Process）：该进程负责协调介质恢复管理工作，适用于物理备库（Physical Standby）。

PR0x（Parallel Recover Process）：进行具体恢复工作的进程，如果是Real-Time Apply模式下，这些进程会从Standby Redo Log（SRL）文件中读取日志，在其他模式下，从归档日志中读取日志然后再进行日志应用工作。

LSP（Logical Standby Process）：适用于逻辑备库（Logical Standby）功能和Physical Standby中的MRP进程类似，负责协调SQL Apply过程。

1.Redo Transport Service（日志传输服务）

Primary Database运行过程中，会源源不断地产生Redo日志，这些日志需要发送到Standby Database。这个发送动作可以由Primary Database的LGWR或者ARCH进程完成，选择哪个进程对数据保护能力和系统可用性有很大区别。

1.1使用ARCH进程传输

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

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

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

（4）ARCH进程通过net把归档日志发送给Standby Database的RFS进程（该进程稍后介绍）

（5）Standby Database端的RFS进程把接受到的日志写入到归档日志；

（6）Standby Database端的MRP进程（该进程对应物理备库）或者LSP进程（该进程对应逻辑备库）在Standby Dtabase上应用这些日志，进而同步数据。

小结：使用ARCH进程传递最大的问题在于，Priimary Database只有在发生归档时才会发送日志到Standby Database。如果Primary Database异常宕机，联机日志中的Redo内容就会丢失，因此使用ARCH进程无法避免数据丢失的问题。要想避免数据丢失，就必须使用LGWR进程传递Redo Log。缺省方式下，Primary Database使用的就是ARCH进程。

1.2使用LGWR进程传输（11g中强调由LNS进程传递）

使用LGWR可以避免数据丢失，其主要有两种同步方式：SYNC（同步）和ASYNC（异步）。

SYNC（同步方式）：

（1）Primary Database产生的Redo日志要通过LGWR进程写到本地日志文件的同时，还要发送给本地的LNSn进程，再由LNSn进程把日志通过网络发送给远程的Standby Database；

（2）LGWR必须等待写入本地日志文件操作和LNSn进程的网络传送都成功，Primary Database上的事物才能提交；

（3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中，注意是Standby Redo Log，不是Online Redo Log；

（4）Primary Database的日志切换也会触发Standby Database上的日志切换，此时Standby Database对Standby Redo Log归档，然后触发Standby Database上的MRP（物理备库）或LSP（逻辑备库）进程恢复归档日志。

因为Primary Database的Redo是实时传送的，所以Standby Database端可以使用两种恢复方式：实时恢复，只要RFS把日志写入Standby Redo Log就会立即进行恢复；归档时恢复，在完成对Standby Redo Log归档时才触发恢复。

ASYNC（异步方式）：

（1）Primary Database产生Redo日志后，LGWR把日志同时提交给日志文件和本地LNS进程。但是LGWR进程只需要成功写入日志文件就可以，不必等待LNS进程的网络传送成功。

（2）LNS进程异步地把日志内容发送到Standby Database。

（3）Primary Database的Online Redo Log写满后发生日志切换，触发归档操作，也出发Standby Database对Standby Redo Log的归档，然后触发MRP或LSP进程恢复归档日志。

1.3补充：

（1）Standby Log File（SRL）

在Data Guard环境下，通常会建议配置一种额外的日志文件Standby Redo Log（SRL），和原有的Online Redo Log相比，SRL有其特殊的要求和作用。

● SRL只在Standby Database上起作用，虽然在Primary Database上也可以配置SRL，但是当数据库处于Primary Role时，SRL是不活动的。只有经过了角色切换，变成了Standby Role时，SRL日志才会变成活动的。

● 对于Standby Role的数据库来说，Online Redo Log不是必须的，在很多时候，Standby Database上虽然以后ORL的设置，但是并没有真正的物理磁盘文件存在，只有当角色转换，Standby变成Primary时，才真正的把Online Redo Log创建出来。

● 对于处于Standby Role的数据来说，它从Primary数据库接收到的日志可以记录在SRL文件中，也可以记录在Archive Log中，具体写在哪个文件中取决于具体配置，但是不会写在Online Redo Log中。

● SRL必须和ORL大小完全一致，在RAC中，按照每个实例N+1的数量关系来配置，比如2个实例的RAC，如果每个实例3组日志吗，则Standby Database上的SRL应该是2*（3+1）=8组。

SRL带来的两大好处：

性能更好：

如果不使用SRL，则Standby数据库的RFS会把接收到的日志记录到归档日志文件中，每当Primary数据库做日志切换时，也会触发Standby数据库对当前归档日志的归档操作。因此它必须等待Standby的RFS进程创建并且初始化下一个归档日志文件，以用来容纳以后传递的Redo内容。这个过程会影响Primary数据库的日志切换进度，对于LNS+ASYNC模式这种情况不再会影响Primary的性能问题，但是仍然会导致Standby Database日志落后于Primary Database。而如果使用SRL的话，因为SRL都是预先创建好的，因此日志切换时，无需额外的文件初始化工作，因此性能要好一些。

支持Real-Time Apply（RTA）：

RTA必须配置Standby Redo Log文件，或者说，正式因为有了SRL，才使得实时恢复成为可能。

（2）Real-Time Apply（实时恢复）

RTA必须配置Standby Redo Log文件，如果配置了该文件，那么MRP进程不再等待归档完成，而是直接从SRL文件中读取内容并应用。如果不是实时恢复的话，则MRP进程是从归档日志中读取日志并恢复的（无论Standby是否使用了Standby Redo Log文件）。理论上说，在RTA模式下Primary和Standby两个数据库的数据能够达到实时同步。但如果Primary数据库的日志生成速度大于Standby数据库上的日志恢复速度，那么即使在RTA模式下，MRP进程也有可能要从归档日志中读取日志内容并恢复，直到赶上了生成日志速度后，才会从SRL中读取日志并开始恢复，这个过程是自动的。

实时恢复有以下几个好处：

a.减少了Switchover和Failover时的等待时间；因为日志随着产生不断被应用，在Switchover活Failover时，需要应用的日志数量很少。

b.提供实时数据；能够从Standby Database上提供实时报表数据分析，把数据汇总、报表等处理压力卸载到Standby数据库上。

c.使用大的日志文件可以减少负载；如果使用归档日志文件进行恢复，Standby的恢复进度总是落后于Primary Database，因此为了减少数据丢失，DBA可能会限制日志文件的大小，当有了RTA后，就可以放心地使用大的日志文件了，这样也减少了日志切换的次数，当日志切换时，会触发检查点动作以及对控制文件、数据文件的更新，这些都属于资源密集型操作，因此加大日志文件会减少这些负载。

2.日志应用服务

日志应用服务，就是在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不支持所有数据类型，可以在视图dba_logstdby_unsupported中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。

物理备用数据库

逻辑备用数据库

根据Redo Apply发生的时间又可以分成两种，一种是实时应用（Real-Time Apply），这种方式必须Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在于减少数据库切换（Switchover或Failover）的时间，因为切换时间主要用在剩余日志内容的恢复上。另一种是归档时应用，这种方式是在Primary Database发生日志切换时，触发了Standby Database的归档操作，归档完成后会触发的恢复（缺省的恢复方式）。

Physical Standby启用Real-Time：

alter database recover managed standby database using current logfile;

Logical Standby启用Real-Time：

alter database start logical standby apply immediate;

查看是否使用Real-Time Apply：

select recovery_mode from v$archive_dest_status;

3.角色转换服务

3.1关于角色转换服务的概念

角色转换服务摘自官方文档如下：

An Oracle database operates in one of two roles: primary or standby. Using Data Guard, you can change the role of a database using either a switchover or a failover operation.

A switchover is a role reversal between the primary database and one of its standby databases. A switchover ensures no data loss. This is typically done for planned maintenance of the primary system. During a switchover, the primary database transitions to a standby role, and the standby database transitions to the primary role.

A failover is when the primary database is unavailable. Failover is performed only in the event of a failure of the primary database, and the failover results in a transition of a standby database to the primary role. The database administrator can configure Data Guard to ensure no data loss.

以下为翻译：

Oracle数据库以两种角色之一运行：主数据库或备用数据库。使用Data Guard，可以使用切换操作或故障切换操作来更改数据库的角色。

一个切换时一个主数据库和其中一个备用数据库之间的角色转换。切换确保没有数据丢失。这通常用于主系统的计划维护。在切换期间，主数据库转换为备用角色，备用数据库转换为主角色。

一个主数据库不可用时进行故障转移。故障切换仅在数据库发生故障时执行，并且故障切换会导致备用数据库转换为主角色。DBA可以配置Data Guard来确保数据不会丢失。

3.2 Data Guard的保护模式

所谓数据保护模式是指Standby Database和Primary Database之间数据同步的程度。Data Guard允许定义3种是数据保护模式，分别是最大保护、最大可用、最下性能。这3种模式的区别在于，当Primary Database发生故障时，Standby Database的数据会和Primary Database有多少差别。

（1）最大保护模式（Maximun Protection）

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

使用这种方式要求Standby Database必须配置Standby Redo Log，而Primary Database必须使用LGWR、SYNC、AFFIRM方式归档到Standby Database，并且用命令定义为最大保护模式。在这种模式下，Primary Database上的每个事物的Redo日志必须在本地和Standby Database上都写入日志文件后才能提交。如果不能写入到Standby Database，Primary Database就会自动关闭以防止数据丢失。但也不是立即关闭，而是不再生成任何Redo，并且不断地尝试去连接Standby Database，这个尝试最多会约有10分钟，因为这一段时间内LGWR进程不能生成任何Redo，因此整个数据库表现挂起。在这种模式下，至少有一个Standby Database是正常的，Primary Database才能正常打开，否则Primary Database都无法打开。

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

（2）最大可用模式（Maximun Availability）

这是另外一种能够实现零数据丢失的数据保护方案。这种模式需要有至少一个Standby Database是通过SYNC和AFFIRM的方式传递数据，并且要使用Standby Redo Log文件才行。在这种模式下，Primary Database发送Redo日志并等待Standby的确认，Standby Database接收到Redo日志，记录到Standby Redo Log中，并返回确认给Primary Database，这时Primary Database上的事物才结束。这和最大保护模式一样。因此，网络状态、Standby数据库的状态都要影响Primary Database的事物性能。等待确认的时间用一个参数NET_TIMEOUT来定义。如果Primary Database在这么长的时间内（缺省30秒）没有收到任何反馈信息，这个Standby Database就会被标志成failed，LGWR进程继续写日志，但是会忽略掉这个failed的Standby Database。如果在NET_TIMEOUT内收到Standby Failed的消息，LGWR和LNS还会继续尝试重新连接，直到最终放弃这个Standby Database。

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

在RAC环境下，如果一个实例认为Standby Database是failed，则自动触发的日志切换会导致所有的实例都停止发送Redo，即便其他实例能够连接到Standby Database。接下来，实例的ARCH进程还继续利用ping机制检测到达Standby Database的连通性，一旦恢复连接，则所有的实例会自动去解决日志裂隙问题，接着所有的实例会进行日志切换，以启动LNS进程，继续发送Redo。这种模式只是尽量避免数据丢失，并不能绝对保证数据完全一致。这种模式要求Standby Database必须配置Standby Redo Log，而Primary DATABASE必须使用LGWR、SYNC、AFFIRM方式归档。

（3）最大性能模式（Maximun Performance）

这个模式是缺省模式，它更加侧重对Primary Database的可用性不造成任何影响。这个保护方式在Primary Database上添加的规则是“在不影响Primary Database性能的情况下，尽可能少的数据丢失”。

Primary Database上的事物的Redo日志只要写到本地日志文件就可以提交，不必等到Standby Database的传递完成。Primary Database的Redo流可以异步地发送到Standby Database。Standby Database的任何故障，以及两者之间的网络故障都不会影响Primary Database的活动，即便网络出现问题，Priamry也只不过暂时中止Redo传送，并等待ARCH进程ping通之后继续重新传送。这种模式可以使用LGWR ASYNC或者ARCH实现，Standby Database也不要求使用Standby Redo Log。

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

3.3定义数据保护模式

保护模式是针对Primary Database进行设置的，这个设置告诉Primary Database必须要遵守的规则。对Standby Database没有作用。数据保护模式在定义数据保护级别的同时，捎带着也同时定义了两个重要信息：

● Primary Database如何向Standby Database传递Redo；

● 当Standby Database发生了故障或者网络出现了故障时，Primary Database应该怎么做。

通过在Primary Database输入以下命令来定义数据保护模式：

alter database set standby database to maximize performance;

alter database set standby database to maxmize availability;

alter database set standby database to maximize protection;

3.3补充：

自动裂隙检测和解决

当Primary Database的某些日志没有成功发送到Standby Database，这时就发生了归档列联系，缺失的这些日志就是裂隙（Gap）。Data Guard能够自动检测、解决归档裂隙，而不需要DBA的介入。

Data Guard解决Gap有两种机制，一种是事前主动式的，另一种是事后响应式的。前一种机制是通过Primary Database的ARCH进程的Ping来完成的，后一种是通过Standby Database的Apply进程完成的，后一种需要配置FAL_CLIENT、FAL_SERVER两个参数（FAL是Fetch Archive Log的首字母缩写）。从其名字就可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database就是FAL CLIENT。但是Standby Database从哪里“取”这些日志呢？FAL SERVER 就是要取日志的地方，可想而知Primary Database就是FAL SERVER，但是FAL SERVER不仅限于Primary Database，其他的Standby Database也可以作为FAL SERVER。

参数FAL_SERVER是用来定义要从哪些数据库获得缺少的日志。这个参数值是Oracle Net Name。在Oracle10.2中，Standby Database不仅可以从Primary Database获得，还可以从其他Standby Database获得缺少的日志，因此这个参数可以定义一个Net Name列表，如：FAL_SERVER='mtx,sundc,warlock'

参数FAL_CLIENT也是一个Oracle Net Name。FAL CLIENT通过网络向FAL SERVER发送请求，FAL SERVER通过网络向FAL CLIENT发送缺失日志，但是这两个连接不一定是一个连接。因此FAL CLIENT向FAL SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL SERVER应该向哪里发送缺失的日志。这个参数值也是一个Oracle Net Name，这个Name是在FAL SERVER上定义的，用来指向FAL CLIENT。

除了自动解决日志确实，DBA也可以手动解决，操作思路如下：

（1）确认Standby Database上缺少的日志；

（2）把这些日志从Primary Database拷贝到Standby Database；

（3）在Standby Database使用命令手工注册这些日志：

alter database register logfile 'logfilename'；

总结：Data Guard和RAC虽然都是Oracle的HA方案，但是两者针对的问题不同。RAC的优势是解决单点故障，并且能提高性能，而Data Guard更侧重于异地容灾，Data Guard的实施成本、维护成本都低于RAC，所以Data Guard是许多小企业钟爱的HA方案。而在银行、证券、电信等要求苛刻的企业，RAC+Data Guard组合由于能提供最有力的数据保护而备受青睐。本文长篇大论阐述了DG的原理，没有什么搭建过程和实际操作，内容甚至比较枯燥乏味，然而工欲善其事，必先利其器，基础原理是技术的基石，至于DG的搭建过程和实际操作，将在以后的文章中涉及。