当前位置：文档库 › ORACLE DATA GUARD

ORACLE DATA GUARD

第1章

Data Guard架构

人为错误、硬件故障、软件故障、网络故障以及火灾、飓风、地震等巨大灾难都会危及作为业务应用程序活力源泉的数据库的可用性。显然，如果无法访问重要数据库，企业运营将受到极大的影响，数据保护和数据可用性的重要性已经众所周知。

作为一名Oracle用户，想必您已经对Oracle Data Guard有所了解。Data Guard专门用来保护Oracle数据，可在提供最高级别的数据保护和可用性的同时，使Oracle数据库保持最卓越的性能。作为Oracle内核自带的一项功能，Data Guard和Oracle的其他高可用性技术集成在一起——典型的有Oracle真正应用集群(Real Application Clusters，RAC)、

Oracle恢复管理器(Recovery Manager，RMAN)和Oracle闪回(Flashback)技术等，这带来

Oracle Data Guard 11g完全参考手册

诸多好处。财务部门将对Active Data Guard备用数据库备感满意，因为Active Data Guard 备用数据库不会在发生故障前因系统、存储和软件闲置而耗费IT成本。世上并无什么万能的产品，但灵活的Data Guard足以满足广泛需要。

从另一方面讲，“全面和灵活”意味着您需要做出很多决定。您可能不清楚如何在自己的环境中以最佳方式部署Data Guard，即使您阅读了Oracle文档，可能还是不完全理解Data Guard的工作原理，您需要更深入地了解Data Guard不同配置选项固有的折衷办法，需要进一步了解如何管理Dada Guard配置。本书将带您更全面深刻地理解Data Guard，从而确保您取得成功。

1.1 Data Guard概述

Data Guard的运行遵循一个简单原则：传输重做数据(redo)，然后应用重做数据。重做数据中包括Oracle数据库恢复数据库事务需要的所有信息。生产数据库(即主数据库)将重做数据传输给一个或多个独立副本(即备用数据库)。Data Guard备用数据库处于连续的恢复状态，验证并应用重做数据，从而与主数据库保持同步。如果因为网络中断或备用数据库断电导致备用数据库与主数据库之间的连接临时中断，Data Guard还会自动重新同步备用数据库。这个简单架构使得当主数据库按计划停运或意外中断后，一个或多个同步副本立即可供使用，从而恢复正常处理。图1-1高度概括了Data Guard传输-应用架构。

主数据库

Oracle数据

文件恢复数据

自动中断处理

备用数据库

恢复数据

Oracle数据

文件

Data Guard，数据库写进程更新主数据库文件。

Data Guard使用已在主数据库上归档的重做

图1-1 概述：Data Guard传输和应用重做数据

重做的含义

重做是Data Guard操作的核心。第3章将详细介绍重做概念。为了理解Data Guard 的工作原理，必须掌握有关重做的基础知识。

第1章Data Guard架构 3

Data Guard优于远程镜像

Data Guard只传输恢复数据库事务所需的重做数据，以便同步备用数据库和相应的

主数据库。Data Guard在备用数据库上应用更改前还执行Oracle验证，以免扩散主数据

库中的受损数据。在Data Guard问世前，公司使用基于存储或主机的远程镜像技术来维

护Oracle数据库文件的一个同步副本。但远程镜像对Oracle事务一无所知，无法区分重

做、撤消(undo)、数据块修改、控制文件写入等操作，要求远程镜像传输针对每个文件

的每次写操作；与Data Guard相比，其生成的网络流量多7倍，网络I/O操作多27倍1。

远程镜像也无法执行Oracle验证，因此无法提供与Data Guard同等的保护级别。考虑到

这些因素及本章后面讨论的一些因素，Data Guard已成为Oracle数据库用户首选的数据

可用性和保护解决方案。

主数据库的事务生成重做记录。Oracle文档给出如下的重做记录定义2：

一个重做记录(又称重做条目)由一组变更向量构成，每个向量描述数据库中一个数

据块的变化。例如，如果更改了雇员表中的薪水值，就生成一个重做记录，其中包含多

个更改向量，来描述撤消段数据块、撤消段的事务表以及表的数据段块的变化。

重做记录包含重新生成数据库更改所需的所有信息。在介质恢复期间，数据库将读

取重做记录中的更改向量，并为相关数据块应用更改信息。

可采用循环方式将重做记录缓存到系统全局区(System Global Area，SGA)的重做日

志缓冲区中。日志写入进程(Log Writer Process，LGWR)是负责管理重做日志缓冲区的数

据库后台进程。LGWR在指定时间将重做条目写入到一个顺序文件，即联机重做日志文

件(ORL)中，从而在重做日志缓冲区中为新条目腾出空间。LGWR总是写入自上次写入

以来复制到重做日志缓冲区的所有重做条目。LGWR写入以下内容：

●提交记录每次事务提交时，LGWR将重做日志缓冲区中的事务重做记录写入

到ORL中，并指定系统更改号(System Change Number，SCN)，来确定每个提

交事务的重做记录。仅当与给定事务关联的所有重做记录都写入ORL时，才能

通知用户进程事务已经提交。

●重做日志缓冲区如果重做日志缓冲区满度达到三分之一，或者距LGWR上次

写入到ORL又过了3秒，则将日志缓冲区中的所有重做条目写入到ORL中。

这意味着可在提交相应事务前将重做记录写入到ORL中。如有必要，介质恢复

将使用重做条目中的撤消信息回滚这些更改。如果数据库写入进程(Database

Writer Process，DBWn)将经过修改的缓冲区数据写入磁盘，而LGWR尚未写完

与修改过的缓冲区相关的所有重做记录，LGWR也会将所有重做记录写入到

ORL中。

值得注意的是，在活动高峰期间，LGWR可使用“组提交”方式写入到ORL。例如，假

1. 请参阅Oracle技术网站https://www.wendangku.net/doc/af8953801.html,/technology/deploy/availability/htdocs/DataGuardRemote-Mirroring.html 上的“Oracle

Data Guard and Remote Mirroring Solutions”。

2. 相关内容请参阅Oracle Database Administrator's Guide 11g Release 1(11.1)一书。

Oracle Data Guard 11g完全参考手册

设一个用户提交了一个事务。当LGWR将提交记录写入磁盘时，其他用户也可能正在发出commit语句。但在LGWR完成前一个写操作后，才会写入到重做日志文件来提交这些事务。在第一个事务的条目写入到重做日志文件后，等待中的事务(尚未提交)的整个重做条目列表可以一并写入到磁盘中；与单独处理每个事务条目相比，这样做可以减少I/O操作(LGWR总是按顺序写入，写得越多，效率越高)。如果提交请求的速率一直很高，从重做日志缓存区执行的每个LGWR写入操作会包含多个提交记录。这会影响重做写入大小(redo-write size)，在Data Guard同步配置中，它是影响数据库性能的多个因素之一，本章后面和第2章将讨论这一点。

LGWR进行处理以确保事务为可恢复状态，而此后DBWn更高效地将缓冲区高速缓存中的更改转储到磁盘后，才对主数据库的数据块进行修改。LGWR写入重做条目(包含事务提交记录)是确定事务已经提交的单一事件。即使DBWn尚未将数据缓冲区中的更改转储到磁盘，Oracle数据库也能发出事务提交的成功代码。这种处理方式可以提高性能，同时确保，如果在将所有数据块写入磁盘前主数据库崩溃，事务也不会丢失。

本节到目前为止讨论的都是Oracle数据库正常运行的情况，与是否使用Data Guard 没有关系。每当提交事务时，都会生成重做数据，这是接下来对Data Guard进行详细讨论的前提。

1.2 重做传输服务

Data Guard重做传输服务(Redo Transport Service)协调从主数据库到备用数据库的重做数据传输过程。同时，主数据库的LGWR进程将重做数据写入到自己的ORL中，一个独立的Data Guard进程从SGA的重做缓冲区中读取信息，交由Oracle Net服务传输到备份数据库，这个进程称为Log Network Server(LNS)。

Data Guard的灵活架构允许将重做数据从一个主数据库直接传给一个或多个(最多9个)备用数据库。Data Guard与Oracle RAC完美集成在一起。一个Oracle RAC数据库有两个或更多服务器(节点)，每个节点运行自己的Oracle实例，共享访问同一个Oracle数据库。主数据库和/或备用数据库都可以用作Oracle RAC数据库。每个活动的主实例都生成自己的重做线程并且拥有相应的LNS进程，后者将重做数据传给备用数据库。

由LNS传输的重做记录在备用数据库由另一个Data Guard进程Remote File Server(RFS)接收。RFS在备用数据库上接收重做数据，然后将其写入一个名为备用重做日志(Standby Redo Log，SRL)文件的顺序文件中。在多备用配置中，主数据库的独立LNS进程管理针对每个备用数据库的重做传输。例如，如果配置为3个备用数据库，每个主数据库实例中就有3个LNS进程处于活动状态。

Data Guard支持两种使用LNS进程的重做传输方法：同步方法或异步方法。图1-2高度概括了重做传输架构。

第1章 Data Guard 架构 5

主数据库

SGA 重做缓冲区 LNS RFS Oracle Net 服务

Data Guard 传输重做数据备用重做日志应用备用数据库 LNS 直接从重做缓冲区传输重做数据——备用数据库上的RFS 进程接收重做数据。图1-2 Data Guard 重做传输进程架构 1.2.1 同步重做传输

同步传输(synchronous transport ，SYNC)又称“零数据损失”方法，因为要等到LNS 确认事务恢复所需的重做数据已被写入备用站点的磁盘上，才允许LGWR 认可提交操作成功。图1-3详细说明了SYNC 。其后的编号列表概述了SYNC 重做传输的每个阶段，对应于图1-3中所示的编号。

联机重做日志 Data Guard 同步传输(SYNC)

LGWR LNS 主数据库

SGA 重做缓冲区备用重做日志 RFS 应用备用数据库 Oracle Net 服务 (3) (1) (3) (1) (2) (1) (3) (1)

(2) (2)

图1-3 SYNC 重做传输架构

错误观点：LGWR 将重做数据传给备用数据库

一个常见的错误观点是LGWR 进程将重做数据传给备用数据库。事实并非如此。Data Guard LNS 进程管理所有同步和异步重做传输。Data Guard 11g 文档将重做传输方法称作SYNC 或者ASYNC ，而不像以前版本那样称作LGWR SYNC 或者LGWR ASYNC ，就是为了消除这种错误观点。

(1) 用户提交一个事务，事务在SGA 中创建一个重做记录。LGWR 从日志缓冲区中

读取重做记录，写入ORL ，然后等待LNS 的确认。

(2) LNS 从日志缓冲区中读取相同的重做记录，通过Oracle Net 服务传给备用数据库。

备用数据库上的RFS 接收重做数据，然后将其写入备用重做日志文件中。

Oracle Data Guard 11g完全参考手册

(3) 当RFS从磁盘接收到一个写完消息时，会将一个确认消息传回给主数据库上的LNS

进程，LNS接着通知LGWR传输完成。LGWR接着向用户发送提交确认信息。

虽然SYNC可以确保得到数据库提交确认的每个事务都已经受到保护，但这种方式会影响主数据库的性能。引起性能下降的原因十分明显：LGWR只有等到数据已在备用数据库受到保护的确认消息后，才能继续处理下一个事务。以下几个因素决定着对应用程序响应速度、数据库吞吐量的影响程度：重做-写入的大小、可用的网络带宽、往返网络延迟(round-trip network latency，RTT)以及备用数据库写入SRL的I/O性能。由于网络RTT随距离的延长而增加，主数据库的性能随之受到影响，实际上这会对主数据库与备用数据库之间的距离形成限制。可在V$SYSTEM_EVENT动态性能视图的等待事件“LNS wait on SENDREQ”中查看这些因素的累积影响(第2章讨论了重做传输的优化)。

读到这里，您可能会问，如果在使用SYNC时网络或者备用数据库出现故障，主数据库会怎样？主数据库会永远等待再不会到来的确认消息吗？请带着这个问题阅读稍后的“Data Guard保护模式”一节以及有关NET_TIMEOUT属性的讨论。

1.2.2 异步重做传输

异步传输(asynchronous transport，ASYNC)与SYNC的不同之处在于，LGWR不必等待来自LNS的确认消息，无论主数据库与备用数据库相距多远，都几乎不会影响到主数据库的性能。

即使由于带宽有限，使得先前事务的重做数据不能立即传给备用数据库，LGWR也将继续确认提交操作成功完成(可以联想到一个水池，其注水速度比排水速度快)。如果LNS赶不上进度，在将重做数据传给备用数据库前就回收了日志缓冲区，LNS将自行转为从ORL读取和发送重做数据(从Data Guard 11g开始提供此项功能)。当LNS赶上进度后，将自行转回到直接从日志缓冲区中读取/发送。

如果ASYNC重做传输的速度落后到在日志切换时LNS还在读取ORL的程度，LNS 将继续执行操作，直到发送完原ORL的内容为止。此后会平滑转回到从当前联机日志文件读取/发送。当LNS赶上LGWR的进度时，会平滑转回到从重做日志缓冲区读取/发送。

Data Guard 11g ASYNC的增强功能

与先前Data Guard版本相比，ASYNC行为发生了变化。Date Guard 11g ASYNC的LNS进程直接从重做日志缓冲区读取数据，但与10.2之前的版本不同，现在再不会出现导致传输终止的“缓冲区变满”状态。相反，LNS进程会平滑切换到从主数据库的ORL 读取和发送。Data Guard 11g ASYNC也可以更高效地利用现有的网络带宽，无论对于任意给定的带宽都能提高网络吞吐量。在网络延迟时间较长的情况下，将更能体现超越先前Data Guard版本的网络吞吐量优势。

第1章 Data Guard 架构 7 优化ASYNC 重做传输

可在视图X$LOGBUF_READHIST 中跟踪日志缓冲区命中率。如果命中率低，则意味着LNS 时常从ORL(而非日志缓冲区)读取。如果重做传输有时停止，不能紧跟上重做数据的生成速度，可考虑增大Data Guard 11g 日志缓冲区来获得更合适的命中率。这会减少或消除由于LNS 从ORL 读取导致的开销。详见第2章。

在极少数情况下，在LNS 发送完原ORL 之前就发生了两次或更多次日志切换，而LNS 仍返回读取当前联机日志文件的内容。在原ORL 和当前ORL 之间归档的任何ORL 将由Data Guard 的间隔处理(gap resolution)进程负责传输；稍后的“自动处理间隔”一节将介绍该进程。注意，如果这种“罕见情况”频频出现，很可能表明没有足够大的带宽来传输重做数据流。

ASYNC 传输行为使得主数据库缓存大量重做数据，这称作传输滞后(transport lag)，但不会终止传输也不影响可用性。虽然ASYNC LNS 读取ORL 造成的相关I/O 开销会轻微影响主数据库的性能，但与高延迟网络上SYNC 的潜在性能影响相比，这是微不足道的。比较图1-4和图1-3可明显看到，ASYNC 比较简洁。ASYNC 唯一的不足之处是增加了数据损失风险。如果某个故障破坏了主数据库，而此时传输滞后尚未降至0，那么传输滞后所包含的任何已提交事务都将丢失。使用ASYNC 时，提供足够大的网络带宽来处理峰值期间高速生成的重做数据，可以最大限度地降低数据损失风险。

联机重做日志 Data Guard 异步传输(ASYNC) LGWR LNS RFS

应用备用数据库主数据库

SGA 重做缓冲区 ? LGWR 与LNS 之间不存在依赖关系。 ? 不存在“缓冲区已满”状态——如果回收重做日志区，LNS 会自动转换到日志文件。 ? 如果从SGA 中读取，LNS 导致的开销为零；如果

从ORL 中读取，LNS 导致的开销最小。

备用重做日志

Oracle Net 图1-4 ASYNC 重做传输架构启用ASYNC 重做传输压缩

Oracle MetaLink Note 729551.1中包含如何使用参数_REDO_TRANSPORT_ COMPRESS_ ALL 启用Oracle Database 11g 第1版和Data Guard ASYNC(最高性能)的重做传输压缩的相关信息。为了启用重做传输压缩，需要获得Oracle Advanced Compression 许可证。

Oracle Data Guard 11g完全参考手册

1.2.3 重做传输压缩

在使用ASYNC时，还需要确定通过压缩重做数据来减少所需带宽是否有利。Oracle企业版11g具有一个新产品，称为“高级压缩选项”。这个新产品包括多项压缩功能，其中一项是Data Guard的重做传输压缩。这项功能起初仅在Data Guard为了处理归档日志间隔而传输日志文件时启用。然而，应用户的要求，Oracle又发表了之前未记录的关于启用ASYNC 重做传输压缩的参数的相关信息(参见上面的“启用ASYNC重做传输压缩”)。

ASYNC重做传输压缩会增加CPU使用率，但在带宽受限的环境中，这决定了能否成功地实现恢复点(数据损失)目标。例如，Oracle日本分公司和日立有限公司测试了工作量为20MB重做数据/秒时，在带宽受限环境下使用压缩功能的影响。此测试的压缩率达到60%(实际压缩率因工作量而异)。使用压缩有显著的好处。这使得传输滞后始终小于10秒，从而达到恢复点目标3。与不启用压缩的基准测试相比，其结果要好得多；在不启用压缩时，传输跟不上主数据库生成重做数据的进度，导致传输滞后，在测试期间，传输滞后随时间推移呈线性增长。此测试还表明，只要有足够的CPU资源用于压缩，对数据库吞吐量或响应时间的影响可降至最低。

1.2.4 自动处理间隔

每当LNS进程停止将重做数据传输到备用数据库，而主数据库却继续提交事务时，就会出现日志文件间隔。每次网络或备用数据库失效时，将可能产生这种情况，具体取决于Data Guard配置的实现方式(稍后“Data Guard保护模式”一节将就此进行讨论)。

在此状态下，主数据库LGWR进程继续写入到当前ORL，填满ORL后，会切换到一个新ORL，此时归档进程(archive，ARCH)会在本地归档已填满的ORL。在繁忙的系统中，在主备之间的连接还原前，此循环会重复多遍，从而生成很大的日志文件间隔。

在中断期间，Data Guard在主数据库上使用ARCH进程连续ping备用数据库来确定其状态。当还原与备用数据库的通信后，ARCH ping进程会查询备用控制文件(通过其RFS进程)，来确定备用数据库从主数据库收到的最后一个完整日志文件。Data Guard确定需要哪些日志文件来重新同步备用数据库，然后立即开始使用其他ARCH进程传输相应文件。在接下来执行日志切换时，LNS会试图连接备用数据库，成功后开始传输当前重做数据，而ARCH进程在后台处理间隔。图1-5中的虚线表示传输和应用所需的重做数据来处理日志文件间隔。一旦备用应用进程能赶上当前重做记录的进度，应用进程就自行转换，不再读取归档重做日志，改而读取当前SRL(假定用户已经配置了Data Guard “实时应用”)。最后需要注意的一点是，从Data Guard 10g开始，主数据库的一个ARCH 进程一直专门负责本地归档，从而确保在处理间隔期间，远程归档操作不影响主数据库回收其ORL4。

第1章 Data Guard 架构 9 重做

缓冲区

SGA SYNC

ASYNC

LNS LGWR 事务

主数据库 Oracle Net 服务 Data Guard 自动间隔处理 RFS 应用来自当前联机重做日志文件的重做信息

备用重做日志备用数据库

重做日志

RFS ping

归档

传输所需的归档日志

来处理日志文件间隔

归档的重做日志归档的重做日志

图1-5 自动处理间隔

自动处理间隔的性能至关重要。主备数据库之间处于非同步状态的时间越久，故障发生时损失数据的风险越大。为使备用数据库赶上进度，主数据库必须以远超平时生成重做数据的速度传输数据。Data Guard 架构允许使用多个后台ARCH 进程来快速处理间隔，与此同时，LNS 进程像通常一样执行当前日志流的SYNC 或者ASYNC 传输。

Data Guard 11g 文档为何未记录ARCH 重做传输

Data Guard 11g 之前记录了三种重做传输方法：SYNC 、ASYNC 和ARCH 。ARCH 指传统归档日志传送，采用这种方法时，Data Guard 等待ORL 归档完毕，然后通过ARCH 进程传送最终归档日志文件的内容。Data Guard 11g ASYNC 增强了性能，Oracle 不再建议将ARCH 作为记录在案的重做传输方法。虽然这样，用ARCH 传输重做数据的功能依然存在，并且可以与客户安装的旧版本向后兼容。当自动处理主备用数据库之间的归档日志间隔时，Data Guard 11g 仍明确使用ARCH 传输基础结构。

1.3 应用服务

Data Guard 提供两种不同的方法在备用数据库上应用重做数据：Redo Apply(物理备用)和SQL Apply(逻辑备用)。下面首先讨论Redo Apply 和SQL Apply 共同的主要目标，然后分析二者的差异。

Data Guard 的宗旨是防止丢失数据，因此，设计目标是让备用数据库成为主数据库的同步副本。Data Guard 的设计纯粹是为了实现对整个数据库的单向复制。Data Guard 还嵌入了safeguard ，以免在备用数据库上对从主数据库上复制来的数据进行任何未授权

Oracle Data Guard 11g完全参考手册

的改动。这些特性解释了Data Guard和Oracle的全功能复制产品Oracle Streams之间的根本区别。Oracle Streams提供多种方法完成颗粒性的多向复制，还可以转换Oracle数据库子集。根据定义，Oracle Streams的额外功能意味着有更多移动部分，通常这会影响性能并增加管理难度。而Data Guard旨在简化操作，体现在可以较简便地实现和管理Data Guard配置。

Data Guard的第二个目标旨在高度分离主数据库和备用数据库。以免主数据库上发生的问题影响到备用数据库，进而危及数据的保护和可用性。这样做也可以防止备用数据库上出现的问题影响到主数据库的可用性或性能。例如，Data Guard应用进程(apply process)在将重做数据应用于备用数据库前对重做数据进行验证，以免主数据库上的物理损坏传播到备用数据库中。还有，回顾一下前面对重做传输服务的讨论：重做传输与备用数据库应用之间不存在任何依赖关系。备用应用的配置方式、应用进程的性能甚至是否启用了应用等事项，不会影响主数据库的可用性、性能及其将重做数据传输到备用数据库的能力。

Data Guard的第三个目标是在主数据库出现故障时提供数据可用性和高可用性。Redo Apply和SQL Apply都能将一个同步备用数据库快速地转换成主角色。这样可以在主数据库出现计划内或计划外中断后保护数据和恢复可用性。

Data Guard应用和Oracle RAC

每个主Oracle RAC实例传送自己的重做线程，由Data Guard应用进程在备用数据库合并后，按SCN顺序应用于备用数据库(第8章将进行更详细的解释)。如果备用数据库是Oracle RAC数据库，则只有一个实例(应用实例)能够合并更改并将更改应用于备用数据库。当使用Data Guard Broker时，如果应用实例由于某种原因出现故障，应用进程将自行转移到Oracle RAC备用数据库中的一个幸存实例上，见第5章。

Data Guard的最后一个目标是为备用系统、存储和软件投资提供高额回报，而不会影响“数据保护和可用性”这项重要使命。Redo Apply和SQL Apply都允许将仍担当备用角色的备用数据库投入生产，同时不影响数据保护或实现恢复时间目标(recovery time objectives，RTO)的能力。

前面介绍了Redo Apply和SQL Apply的共同点，您需要理解两者的差异，从而确定哪类备用数据库最适合您的需要。下面简要介绍Redo Apply和SQL Apply的特色和优势，其他详情请参见第2章～第4章。

1.3.1 Redo Apply

Redo Apply(物理备用)维护的备用数据库是与主数据库逐块对应的精确物理副本。当备用数据库上的RFS进程收到从主数据库传来的重做数据，然后将其写入SRL时，Redo Apply使用介质恢复将SRL中的重做记录读入内存，接着直接在备用数据库上应用更改向量。介质恢复并行执行，以便获得卓越性能(见图1-6)。它包括一个介质恢复协调器(Media Recovery Coordinator)以及多个并行应用进程。介质恢复协调器(MRP0)管理恢复

第1章Data Guard架构11

会话，按SCN顺序合并来自多个实例的重做数据(在使用Oracle RAC主实例的情形下)，

然后将重做数据解析到按应用进程划分的更改映射中。应用进程(pr00、01、02…)读取数

据块，组装映射中的重做更改，然后将重做更改应用于数据块。Redo Apply将应用进程

数量自动配置为比备用数据库系统中的CPU数量少1。由于使用了此架构，而且Oracle Database 11g显著增强了介质恢复功能，所以取得了十分卓越的性能。Oracle针对Data Guard Redo Apply的基准测试表明，在承担OLTP (联机事务处理)工作负荷时其速度高达

47MB/s，在直接路径加载情形下速度高达112MB/s。5

并行介质恢复

介质恢复协调器(MRP0)

协调器&线程合并器

配备8个CPU的服务器应用进程(pr00) 应用进程(pr01)应用进程(pr02)应用进程(pr03)应用进程(pr04)应用进程(pr05)应用进程(pr06)

图1-6 重做应用的并行介质恢复(物理备用数据库)

1．Oracle Active Data Guard 11g

在Oracle Database 11g企业版中，Active Data Guard选项极大地增强了仍担当备用角色的物理备用数据库的作用。在以前的Data Guard版本中，如果启用了介质恢复，数据库只能处于装载(mount)状态。当启用介质恢复时，始终围绕获得最高性能来优化介质恢复，而非为查询提供一个读一致视图。要查询物理备用数据库，必须禁用介质恢复，并以只读模式打开备用数据库。由于一旦禁用介质恢复功能，备用数据很快便会过时，所以由物理备用数据库承担从主数据库卸载的只读查询和报表或服务的能力十分有限。

Active Data Guard 11g通过使用“查询”SCN，在不影响备用应用性能的情况下，解决了读一致性问题。备用数据库上的介质恢复进程在全面应用了一个事务的所有相关更改(新查询SCN也传给Oracle RAC备用数据库的所有实例)后递增查询SCN。用户可在备用数据库V$DATABASE视图的CURRENT_SCN列中查看对应的查询SCN。执行只读操作的用户只能看到对应查询SCN的数据，确保与主数据库保持读一致性。这样可在介质恢复启用时以只读模式打开物理备用数据库，从而可以从主数据库卸载只读工作负荷。

2．损坏保护

Data Guard Redo Apply可防止将主数据库上的物理损坏应用于备用数据库，从而提供了卓越的数据保护能力。以SYNC或ASYNC模式直接从SGA传输的重做数据与主站点上的组件故障造成的物理I/O损坏完全隔离。备用数据库上Redo Apply执行的软件代

5. 请参阅Active Data Guard 11g与介质恢复最佳实践的相关内容，网址：https://www.wendangku.net/doc/af8953801.html,/technology/ deploy/availability/ pdf/maa_wp_11gr1_activedataguard.pdf。

Oracle Data Guard 11g完全参考手册

码路径也与主数据库上的完全不同——使备用数据库与影响主数据库的软件错误进一步分离。在将重做数据应用于备用数据库前，Data Guard使用Oracle进程对其进行验证。

在以下主要接口上检测损坏情况：

●在主数据库上的重做传输期间在Oracle Database 11g主数据库上，使用DB_

ULTRA_SAFE参数启用损坏检测/保护功能的效果最好(涉及LGWR、LNS和

ARCH等进程)。

●在备用数据库上的Redo Apply期间在Oracle Database 11g备用数据库上，使用

DB_BLOCK_CHECKSUM=FULL和DB_LOST_WRITE_PROTECT=TYPICAL参

数启用损坏检测/保护功能的效果最好(涉及RFS、ARCH、MRP和DBWR等进程)。

远程镜像和损坏

我们经常听到用户说，在使用存储区域网络(storage area network，SAN)或基于主机的远程镜像时，主站点上的组件故障造成的物理损坏被镜像到远程卷上，使得这些副本也不能使用了。因为在启用镜像会话时，Oracle不能装载到远程卷上，所以不能在将更改应用于备用数据库前执行端到端的验证。更糟的是，远程镜像用户通常直到使用备用数据库时才知道有问题——那时为时已晚。Data Guard则不存在这些限制。

如果Redo Apply在备用数据库上检测到任何受损的重做数据，Data Guard将使用间隔处理进程自动从主数据库提取相关归档日志的新副本，并且希望原数据并未受损。

物理备用数据库使用Oracle Database 11g中的新参数DB_LOST_WRITE_PROTECT来提供业界独特的技术来防止由写丢失造成的损坏。如果I/O子系统确认已完成写操作，但实际上并未写入永久存储器，则发生了写丢失(lost write)。对于后续块读取，I/O子系统返回数据块的过期版本，过期版本用来更新其他数据块，从而将错误传播到整个数据库。在设置了DB_LOST_WRITE_PROTECT初始参数后，数据库会在重做日志中记录缓冲区高速缓存块读取信息，此信息可用于检测写丢失。只有使用了Data Guard物理备用数据库，才能使用写丢失检测进行有意义的保护。在主数据库和备用数据库都将DB_LOST_WRITE_PROTECT参数设为TYPICAL(若如前所述在主数据库上设置了DB_UL TRA_SAFE，则将在主数据库上自动设置DB_LOST_WRITE_PROTECT=TYPICAL)。当备用数据库使用Redo Apply应用重做数据时，将读取相应的数据块，并将SCN与重做日志中的SCN进行比较，可能的比较结果如下：

●主数据库的数据块SCN比备用数据库的数据块SCN小，说明主数据库上出现了

写丢失，此时会发出外部错误(ORA-752)。对于ORA-752错误提示，建议的响应

操作是执行到物理备用数据库的故障转移，然后重建主数据库。

●数据块的SCN更大，说明备用数据库上出现了写丢失，此时会生成内部错误

(ORA-600 3020)。如有可能，需要使用受影响的数据文件在主数据库的备份来修

复备用数据库。否则，必须重建备用数据库。

第1章Data Guard架构13

3. Redo Apply的优势

用Redo Apply维护的物理备用数据库通常堪称最佳的灾难恢复(disaster recovery，DR)选项，具有简单、透明、性能卓越和数据保护的特点。下面归纳了物理备用数据库

的优势：

●全面应用和数据透明——不存在数据类型或其他约束。

●性能卓越，最易于管理，部件移动最少。

●Oracle在应用前执行端到端验证，提供了防止物理损坏(包括由于写丢失造成的损

坏)的最佳方式。

●能在提供灾难恢复能力的同时，支持最新的只读查询和报表服务(Active Data

Guard 11g)。

●能在提供灾难恢复能力的同时，从主数据库卸载备份。

●在对主数据进行持续的DR保护的同时，支持QA测试和其他需要读写访问的活

动(Data Guard 11g快照备用)。

●从Oracle Database 11g开始，可以执行数据库滚动升级(临时逻辑)。

用物理备用滚动升级数据库

通过KEEP IDENTITY子句和SQL Apply，Data Guard 11g允许将物理备用数据库用

于滚动数据库升级。物理备用数据库暂时转换成临时逻辑备用数据库，然后升级到新版

本。虽然需要同时在主系统和备用系统上升级Oracle Home，但只需在临时逻辑备用数

据库上执行一次数据库升级脚本。随后进行一次切换，原来的主数据库转回为物理备用

数据库，由于执行此前在临时逻辑备用数据库上运行的升级脚本而生成的重做数据将应

用于物理备用数据库对其进行更新(详见第11章)。这就消除了仅为滚动数据库升级而为

逻辑备用数据库部署附加存储所需的开支和工作。

1.3.2 SQL Apply

SQL Apply(逻辑备用数据库)使用逻辑备用进程(Logical Standby Process，LSP)将更改

协调应用于备用数据库。SQL Apply需要的进程数量比Redo Apply多，如图1-7所示，

详细讨论见第4章。组成SQL Apply的多个进程读取SRL，并通过将重做数据转换为逻

辑更改记录(logical change record，LCR)来“挖掘”重做数据，然后构建SQL事务并将

SQL应用于备用数据库。由于重建进程和重放工作量包含更多移动部件，所以比Redo Apply需要更多内存、CPU和I/O资源。

SQL Apply也不提供与Redo Apply同一级别的透明性。SQL Apply的性能因事务状

况而异。SQL Apply并非支持所有数据类型(如对象关系格式的XML，以及Oracle提供

的类型，如Oracle Spatial、Oracle Intermedia和Oracle Text等)。这些因素共同导致SQL Apply比物理备用数据库需要执行更多性能测试、调优和管理工作(请参阅Oracle

Oracle Data Guard 11g完全参考手册

MetaLink中的生动说明，其中深入分析如何优化SQL Apply性能6)。这些因素的表现程度因基于SQL的复制解决方案(由Oracle或第三方提供的解决方案)而异，由于SQL Apply 与Oracle数据库内核浑然天成地集成在一起，所以具有超越第三方SQL复制产品的先天优势。

未组合到事务中的

逻辑更改记录

来自主

数据库的重做数据Reader Preparer 生成器

LCR

共享池

事务组日志挖掘

应用处理

逻辑备用数据库Applier

应用的

事务

协调器

(LSP) 按依赖关系

排序的事务

分析器重做记录

图1-7 SQL Apply处理架构

SQL Apply的优势

与Redo Apply相比，SQL Apply执行的附加处理也是其优势源泉。SQL Apply应用SQL，因此在启用应用期间，逻辑备用数据库以读写模式打开。虽然SQL Apply禁止对所复制的数据加以修改，但逻辑备用数据库更灵活，允许对与主数据库无关的已添加到备用数据库的本地表和模式执行插入、更新和删除等操作。这是十分重要的，例如，要用备用数据库从主数据库卸载一个报表应用程序，该程序需要经常对全局临时表或仅存在于备用数据库上的其他本地表执行写操作。逻辑备用数据库还允许创建主数据库上没有的本地索引和物化视图。这样，维护代价十分高昂的索引(就其对OLTP系统的影响而言)可在逻辑备用数据库上实现，使其在优化报表和浏览活动方面发挥重要作用。SQL Apply的优势如下：

●与基于SQL的第三方复制产品相比，内置的Oracle功能更简单，对主数据库的

性能和管理影响更小。之所以具有这样的优势，是因为其本着单向复制整个主

数据库这样一个简化设计的目标。重做传输服务高效传输所有主数据库重做数

据，SQL Apply总在备用数据库上执行所有处理。

●SQL Apply活动时，备用数据库以读写模式打开。

●SQL Apply维护一个“保护”设置，防止应用程序修改备用数据库中的数据。

●SQL Apply可用来将数据库滚动升级到Oracle新版本或新补丁集。从Oracle Database

10.1.0.4版本开始这可用于逻辑备用数据库，从Oracle Database 11.1.0.6版本开始可用

于物理备用数据库(使用KEEP IDENTITY子句)。

6. 请参阅MetaLink Note 603361.1：“向开发人员和DBA提出的主动优化SQL Apply的提示”。

第1章Data Guard架构15

错误观点：SQL Apply功能尚未成熟

在Oracle 9i中首次发布SQL Apply时，当时的SQL Apply确实不够成熟，导致早期

用户认为SQL Apply无法成功用于生产环境。这个看法在今天已经过时了，因为SQL

Apply历经在几个重要Oracle版本中的改进，已经成熟了。日益增长的在生产环境中成

功使用Data Guard 10g Release 2的数量证实了这一点。Data Guard 11g SQL Apply在满足

其所定位的需求上，是一个极具吸引力的解决方案。

如果满足SQL Apply所需的前提条件，还要求备用数据库在为主数据库提供DR保

护的同时以读写模式打开，那么建议您使用SQL Apply。

1.3.3 在难以取舍的情况下同时使用二者

可能很难在Redo Apply和SQL Apply之间做出抉择。您需要获得Redo Apply在数

据保护和可用性方面的简易性和卓越性能。使用Active Data Guard 11g时，Redo Apply

还是从主数据库卸载只读查询的出色解决方案。但有些情况下，可能遇到报表应用程序

需要对备用数据库进行读写访问的情形，这就需要SQL Apply来获得更大的灵活性。Data Guard支持混合物理和逻辑备用数据库的多备用配置，十分灵活，可以使用户在单个Data Guard配置中以最佳方式满足所有需要。7

错误观点：备用数据库应用性能会影响主数据库

一个常见的错误观点是备用应用性能会影响主数据库。由于其他竞争RDBMS产品确

实没有提供与Data Guard同等的隔离级别，这个观点可谓深入人心。实际上，在Data Guard

配置中，备用数据库应用性能对主数据库的可用性或性能没有任何影响。

1.4 Data Guard 保护模式

很多DBA对Data Guard SYNC重做传输的出色高级数据保护能力十分感兴趣。但

是他们经常需要考虑以下事项：如果主数据库未从备用数据库收到确认消息(原因是备用

数据库不可用或出现网络故障)，则主数据库将被无限期挂起。大多数DBA最不愿意告

诉客户这样的事情：虽然主数据库十分健康，但除非能确保数据已在备用数据库上受到

保护，否则就拒绝处理后续事务。此外，您可能另有一组要求，即使影响了主数据库的

可用性，也要绝对保证数据已得到保护。这两种情况都可以使用SYNC传输来提供零数

据损失保护，但它们需要对网络或备用数据库故障做出不同响应。Data Guard保护模式

实施了一些规则，来管理配置对故障的响应方式，从而达到具体的数据保护、可用性和

性能目标。Data Guard可在单个Data Guard配置中支持多个备用数据库，可以根据需要

7. 请参阅“管理包含多个备用数据库的Data Guard配置——MAA最佳实践”，网址为https://www.wendangku.net/doc/af8953801.html,/ technology/deploy/ availability/pdf/maa10gr2multiplestandbybp.pdf。

Oracle Data Guard 11g完全参考手册

为它们设置相同(或不同)的保护模式。Data Guard保护模式分为最高性能、最高可用性和最大保护。

1.4.1 最高性能

这个模式较注重主数据库的性能，较轻视数据保护。它需要使用ASYNC重做传输，这样LGWR进程从不等待备用数据库的确认消息。主数据库的性能和可用性不受重做传输的影响，也不受主备用之间的网络连接状况或备用数据库可用性的影响。如前所述，Data Guard 11g中的ASYNC得到了增强，从而成为“最高性能”模式下的默认重做传输方法。在Data Guard 11g中，Oracle建议不要再为“最高性能”模式使用ARCH传输，因为与ASYNC相比，ARCH提供的数据保护级别更低，而且不具备性能优势。

1.4.2 最高可用性

这个模式最强调可用性，其次强调零数据损失保护。它需要使用SYNC重做传输，因此从备用数据库收到“重做数据已写入磁盘”确认消息所需的时间会影响主数据库的性能。但在主数据库出现故障时，通常可以百分之百地保证数据得到了保护。

然而，有些事件虽然对主数据库的可用性没有影响，却影响其将重做数据传给备用数据库的能力。例如，如果网络或备用数据库出现故障，将无法向备用数据库传输信息，而主数据库却仍能继续接收新事务。将主数据库配置为“最高可用性”时，其最长等待秒数由NET_TIMEOUT的值决定(用户可配置此参数，详见第2章)，此后将放弃备用目标，即使仍无法与备用数据库通信，也允许主数据库继续进行处理。这种方式可以防止因主备用数据库之间的通信故障而对主数据库的可用性造成影响。

当主数据库重新建立与备用数据库的连接后，Data Guard将自动重新同步备用数据库(使用前面介绍的间隔处理进程)。确切地讲，一旦超过NET_TIMEOUT秒，LGWR进程就与LNS进程中断连接，然后在无备用数据库的情况下确认提交并且继续处理事务。

在当前ORL变满后，LGWR会轮换到一个新ORL。在打开新ORL后，LGWR在必要时终止之前的LNS进程，启动一个新LNS进程并尝试与备用数据库建立新连接。如果成功，新ORL内容照常传输。如果LNS在NET_TIMEOUT秒内还是没有成功连接，LGWR 就像以前一样工作，认可当前提交，在无备用数据库的情况下继续处理事务。会在每次日志切换时重复这个过程，直到LNS成功连接到备用数据库为止(可使用REOPEN属性调整LGWR重新连接出现故障的备用数据库的频率，见第2章)。

与此同时，主数据库归档了一个或多个尚未完整传给备用数据库的ORL。一个Data Guard ARCH进程持续针对备用数据库执行ping操作，直到再次连接成功为止，然后确定备用数据库上哪些归档日志不完整或缺少。了解这些信息后，Data Guard立即开始传输重新同步备用数据库需要的所有日志文件。当ping进程与备用数据库建立连接后，Data Guard还将在主数据库上强制做一次日志切换。这将关闭当前联机日志文件，初始化一个新的LNS连接以便立即传送当前重做数据，防止在间隔再同步过程中，重做传输进一步滞后。在这个过程中，仅当在自动重新同步进程尚未完成前，主数据库又出现一次故障时，才可能损失数据。

第1章Data Guard架构17 1.4.3 最大保护

顾名思义，该模式将数据保护放在首要位置。它也需要SYNC重做传输。直到收到

配置中至少一个备用数据库的确认消息(指出恢复事务所需的数据已经可靠地保存在磁

盘上)，主数据库才向应用程序确认提交。它对主数据库的性能影响与“最高可用性”相

同，不同之处在于它不考虑NET_TIMEOUT参数。如果主数据库未能从SYNC备用数

据库收到确认消息，主数据库将停下来并最终中止，防止出现未保护提交的情形。此行

为保证对数据提供完备保护，即使发生多个故障事件也同样如此(例如，首先是网络中断，

然后主数据库出现故障)。需要注意，实现“最大保护”的大多数用户至少会在不同位置

配置两个SYNC备用数据库，这样当一个备用数据库出现故障时，并不会影响主数据库

的可用性。

1.5 角色管理服务

这里回顾一下迄今所学的知识。Data Guard传输和应用服务的要点如下：

●Data Guard只需传输重做记录来同步远程备用数据库。

●传输有同步传输(零数据丢失)和异步传输两种。

●同步传输影响主数据库的吞吐量和响应速度，原因是主数据库需要耗费一定时

间接收来自远程备用数据库的确认消息(指出数据已经可靠地保存在磁盘上)。可

以控制主数据库等待确认消息的时长，以免在主数据库失去与备用数据库的连

接时，陷入无限期的挂起状态。

●异步传输绝不会造成主数据库停滞，也不会对主数据库的性能或响应速度造成实

质影响。

●有两种不同的备用数据库类型，即Redo Apply(物理)和SQL Apply(逻辑)。两种

类型各有优势，无论选择哪种方法，备用应用性能都不影响主数据库的可用性

或性能。所有重做数据在应用于备用数据库前都先由Oracle进行验证，以免主数

据库上出现的物理损坏或写丢失影响备用数据库。所有Data Guard备用数据库

都处于活动状态，打开后可支持只读查询和报表，以卸载主数据库的负荷，并

从备用系统投资上获得更高回报。

●Data Guard保护模式控制配置响应故障的方式，从而达到可用性、性能和数据保

护目标。除非明确进行配置以达到最高数据保护级别，否则备用数据库的可用

性或主备数据库之间的网络连接都不影响主数据库的可用性。

接下来讨论的Data Guard架构部分是角色管理服务，它可将备用数据库快速转换成

主数据库角色。Data Guard文档中使用术语“切换”描述计划中的角色转换，通常是为

了尽量减少计划内维护期间的停机时间。术语“故障转移”用于描述在发生计划外事件

时进行的角色转换。

Oracle Data Guard 11g完全参考手册

1.5.1 切换

切换是计划内的事件，Data Guard 颠倒主数据库和备用数据库的角色。在计划内维护期间，切换对于尽量缩短停机时间非常有用。最明显的例子是使用滚动数据库升级来迁移到新版Oracle数据库或补丁集。在迁移到新存储系统(包括Exadata storage8)、迁移卷管理器(例如，迁移到Oracle Automatic Storage Management)、从单实例迁移到Oracle RAC、执行技术更新、维护操作系统或硬件甚至搬迁数据中心时，Data Guard切换还能尽量缩短停机时间。切换命令执行以下几个步骤：

(1) 通知主数据库切换操作即将开始。

(2) 切断所有用户与主数据库的连接。

(3) 生成特殊重做记录来指示重做结束(End Of Redo，EOR)。

(4) 将主数据库转换为备用数据库。

(5) 备用数据库应用最后的EOR记录，确认没有丢失数据后，从备用转为主角色。

新的主数据库自动开始将重做数据传给配置中的其他所有备用数据库。在多备用配置中，转换按顺序进行，因为每个备用数据库收到原主数据库发送的相同EOR记录，它们知道收到的下一条重做数据来自刚成为主数据库的数据库。

使用切换减少计划内维护期间的停机时间的基本原则通常是相同的。当在备用数据库上实现需要的更改(例如补丁升级，完全Oracle版本升级等)时，主数据库正常运行，不会受到影响。结束后，将运行新版本的备用点转入生产。在移动数据中心时，只需在新数据中心创建一个备用数据库，然后使用切换方式使数据库投入生产。

另外，如果执行的维护会影响主站点的可用性，则在此之前将生产切换到备用站点，以便在站点维护的整个过程中应用程序始终可供使用。完成工作后，Data Guard将重新同步两个数据库，将生产再切换回原来的主站点。无论执行计划内维护需要多长时间，生产数据库的停机时间也只是切换所用的时间——根据Oracle最佳实践的文档记录，这项任务在60秒内即可完成9，在最近Oracle日本分公司和IBM合作完成的验证测试中，5秒钟即可完成10。

考虑到Oracle在同一Data Guard配置中日益支持不同的主/备用系统，切换操作显得更有价值。例如，Oracle Database 11g可以支持Windows主数据库和Linux备用数据库，或者32位Oracle主数据库和64位Oracle备用数据库，以及其他混合配置选择11。

这方便了在所支持的平台组合之间迁移，只需在新平台上创建一个备用数据库然后进行切换，几乎不存在任何风险。大多数情况下，可以继续保持以前平台上的旧数据库与新数据库的同步，以便进一步降低风险。如果出现出乎意料的问题，可回退到以前的平台，

8. 请参阅MAA“迁移到Oracle Exadata存储服务器的最佳实践”，网址为www. https://www.wendangku.net/doc/af8953801.html,/technology/ products/bi/db/

exadata/ pdf/migration-to-exadata-whitepaper.pdf。

9. 请参阅Data Guard 10g的MAA“切换和故障转移最佳实践”，网址为www. https://www.wendangku.net/doc/af8953801.html,/technology/deploy/availability/pdf/MAA_

WP_10gR2_SwitchoverFailoverBestPractices.pdf。

10. 请参阅Oracle日本分公司GRID中心性能验证：IBM Power System上的Data Guard SQL Apply，网址为https://www.wendangku.net/doc/af8953801.html,/

technology/deploy/availability/pdf/gridcenter_sqlapply_validation_powersystem. pdf。

11. 请参阅MetaLink Note 413484.1。

第1章Data Guard架构19 只需执行第二次切换，不会丢失数据。

1.5.2 故障转移

故障转移用于描述因计划外事件导致的角色转换。这个过程与切换类似，不同之处

在于主数据库没有机会写一条EOR记录。从备用数据库的角度看，重做传输突然间停止。

备用数据库忠实地应用接收到的最后一个提交事务的重做数据，等待重做传输恢复。此

时故障转移是否会导致数据丢失呢？这将取决于发生故障时所启用的Data Guard保护模

式。在“最大保护”模式下不会丢失任何数据。在“最高可用性”模式下也是零数据丢

失，除非以前的故障(如网络故障)中断了重做传输，并且允许主数据库与备用数据库产

生差异。如果第二次故障破坏了主数据库，那任何已提交的事务(但尚未提交给备用数据

库)将会丢失。与此类似，使用“最高性能(ASYNC)”的配置将丢失主数据库发生故障前

尚未传给备用数据库的所有已提交事务。

错误观点：故障转移后必须重建原来的主数据库

从Oracle 10g Release 1开始，如果故障转移发生前在主数据库上启用了闪回数据库，

通常可以避免用新备份来还原出现故障的主数据库(至少需要60分钟闪回保留期)。如果

可以修复故障主数据库，而且数据库进入装载状态，它就可以闪回到备用数据库变为主

数据库之前的SCN，然后转换为备用数据库。在使用Redo Apply时，通过在新主数据库

上发出以下查询来确定此SCN：

SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN)

FROM V$DATABASE;

一旦完成闪回操作，就可将故障主数据库转换为物理备用数据库，Data Guard可以

将其与新主数据库重新同步，使配置快速返回到受保护的状态。这个过程在逻辑备用数

据库中更复杂些，但最后结果是相同的。

DBA可选择手动故障转移或者自动故障转移。在执行手动故障转移时，管理员可完

全控制角色转换；但这种方式会延长中断时长，原因是管理员接到通知、作出响应、评估

发生的事件、作出故障转移决策以及手动执行命令都需要耗费时间。相比之下，Data Guard

的快速启动(Fast-Start)故障转移12功能(见图1-8)可自动检测出故障，评估Data Guard配置

的状态，然后酌情执行针对预先选择的备用数据库的故障转移(第8章将详细讨论快速启

动故障转移)。无法哪种情况，如果决定要执行故障转移，将可以在很短的时间内完成。Oracle对Data Guard 11g的基准测试表明，数据库故障转移的时长为14～25秒，具体时长

12. 请参阅Data Guard 10g的MAA“快速启动故障转移最佳实践”部分，网址为https://www.wendangku.net/doc/af8953801.html,/technology/deploy/availability/

pdf/MAA_WP_10gR2_FastStartFailoverBestPractices.pdf。

Oracle Data Guard 11g 完全参考手册

20 取决于配置13。 Data Guard 观察器(Observer)

FastStartFailoverThreshold

站点2 备用数据库

站点1

主数据库

Data Guard

快速启动故障转移最高可用性(SYNC)

最高性能(ASYNC)

FastStartFailoverLagLimit 快速启动故障转移目标

图1-8 Data Guard 快速启动故障转移架构

选择手动故障转移或者自动故障转移

手动还是自动？如何确定用哪种故障转移方式合适呢？这取决于多个因素：RTO 目标，当前环境中应用程序故障转移的复杂性，以及个人对自动或手动过程的偏好。无论如何，因为涉及人的因素，手动故障转移所需的时间更长。即使一直监控主数据库的状态，并当问题出现时自动向管理员发出警报，管理员也必须耗费时间作出响应，评估当前状况，然后再决定做什么。这些会消耗时间，而且发生不同事件时所需的时间也不同，从而造成故障转移时间难以预测。如果恢复时间目标足够宽松，手动故障转移也可以达到要求，那么付出额外努力来实现故障转移自动化也不会带来什么好处。但如果恢复时间目标更紧迫，手动故障转移将很难(甚至无法)满足目标。恢复时间目标越紧迫，实现Data Guard 快速启动故障转移的好处越大。

在考虑采用手动还是自动故障转移时，应用程序复杂性是第二个需要考虑的因素。例如：美国政府的一个Data Guard 用户从2003年以来一直运行一个复杂的应用程序环境，在多个数据库中执行分布式事务。在采用“最大保护”或者“最高可用性”模式时，使用故障快速切换可实现零数据丢失。备用数据库会假设主角色没有丢失数据，其他任何参与分布式事务的数据库也没有关联的恢复。但“最高性能”模式下的自动故障转移造成的数据丢失是一个棘手的问题。由于Data Guard 还不能协调参与分布式事务的多个数据库的时间点恢复，因此用户需要手动完成一些工作。考虑到主数据库与备用数据库相距1000多英里，该用户配置了“最高性能”模式。虽然Data Guard 11g 在“最高性能”模式下支持自动故障转移，但对该用户来说这并不实用，因为在故障转移造成数据丢失

13. 请参阅Data Guard 10g 的MAA “切换和故障转移最佳实践”部分，网址为https://www.wendangku.net/doc/af8953801.html,/technology/deploy/availability/ pdf/MAA_WP_10gR2_SwitchoverFailoverBestPractices.pdf 。