Data Guard

容灾与复制

高可用性挑战

影响业务的停机时间可能是计划的或计划外的。计划外停机时间可能是由硬件或系统故障、数据/存储故障、人为错误、计算机病毒、软件故障、自然灾害或恶意行为引起的。某项业务可能还要不得不承受因计划维护（如系统升级）而造成的计划停机时间。

设计业务连续性策略的公司必须创建能够有效处理这些挑战的业务连续性计划 (BCP)。对 BCP的一个关键性要求就是，它必须保护业务数据，因为数据是公司最重要的资产之一—无论它是工资/员工信息、客户记录、宝贵的研究、财务记录、历史信息等。如果公司丢失了数据，则无法轻易恢复；而且重新构建或重新生成这些数据的代价可能极其高昂（如果还有可能的话），这将严重影响公司继续经营的能力。

Oracle Data Guard以最低的成本实现最大的数据保护

Oracle Data Guard 旨在满足企业非常重要的业务连续性需要。它提供一套广泛的数据保护和灾难恢复 (DR)特性，帮助企业从可能给 Oracle Data Guard —以最低的成本实现最大的数据保护 Oracle数据库造成不利影响的灾难、人为错误和毁坏中幸免。

什么是 Oracle Data Guard？

OracleData Guard是管理、监控和自动化软件的基础架构，它创建、维护和监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。

 Data Guard使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千英里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时，DataGuard可以将任意备用数据库切换到生产角色，从而使与中断相关的停机时间减到最少，并防止任何数据丢失。作为 Oracle数据库企业版的一个特性推出的 Data Guard 能够与其他的 Oracle高可用性 (HA) 解决方案（如真正应用集群 (RAC)和恢复管理器 (RMAN)）结合使用，以提供业内前所未有的高水平数据保护和数据可用性。

Oracle Data Guard功能

Oracle Data Guard 包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。DataGuard利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。通过 Data Guard，还将重做数据传输到备用站点上，并应用到备用数据库中，从而使备用数据库与主数据库保持同步。Data Guard 允许管理员选择将重做数据同步还是异步地发送到备用站点上。备用数据库的底层技术是Data Guard重做应用（物理备用数据库）和 Data Guard SQL应用（逻辑备用数据库）。

物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库结构，并且使用 Oracle 介质恢复进行更新。

逻辑备用数据库是一个独立数据库，它与主数据库包含相同的数据。它使用 SQL 语句进行更新，其相对优势是能够并行用于恢复以及诸如报表、查询等其他任务。

 Data Guard简化了主数据库和选定的备用数据库之间的转换和故障切换，从而减少了由计划停机和计划外故障所导致的总停机时间。主数据库和备用数据库以及它们的各种交互可以使用SQL*Plus来进行管理。为了获得更简便的可管理性，Data Guard 还提供了一个分布式管理框架（称为 Data Guard Broker），它不但自动化了 Data Guard配置的创建、维护和监控，并对这些操作进行统一管理。管理员可以使用 Oracle Enterprise Manager或Broker 自己的专用命令行界面(DGMGRL)来利用 Broker 的管理功能。

下图显示了 OracleData Guard组件。

一．Oracle Data Guard的好处

“Data Guard 使灾难恢复过程自动化，并且与以前的方法相比，将Fidelity 的数

据丢失可能性降低了一个数量级。”

数据体系结构和服务

Fidelity Investments

Oracle Data Guard提供了以下好处

灾难恢复和高可用性

Data Guard 提供了一个高效和全面的灾难恢复和高可用性解决方案。易于管理的转换和故障切换功能允许主数据库和备用数据库之间的角色转换，从而使主数据库因计划的和计划外的中断所导致的停机时间减到最少。

完善的数据保护

使用备用数据库，DataGuard可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传

播到备用数据库上。同样，导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后，在将重做数据应用到备用数据库时会对其进行验证。

有效利用系统资源

备用数据库表使用从主数据库接收到的重做数据进行更新，并且可用于诸如备份操作、报表、合计和查询等其他任务，从而减少执行这些任务所必需的主数据库工作负载，节省

宝贵的 CPU和 I/O周期。使用逻辑备用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最后，可以在维护的表上创建额外索引和物化视图，以获得更好的查询性能和适应特定的业务要求。

灵活的数据保护功能，在可用性与性能要求之间取得平衡

Oracle Data Guard 提供了最大保护、最高可用性和最高性能等模式，来帮助企业在系统性能要求和数据保护之间取得平衡。

自动间隔检测及其解决方案

如果主数据库与一个或更多个备用Oracle Data Guard

—以最低的成本实现最大的数据保护 第 6 页数据库之间的连接丢失（例如，由于网络问题），则在主数据库上生成的重做数据将无法发送到那些备用数据库上。一旦重新建立连接，Data Guard就自动检测丢失的存档日志序列（或间隔），并将必要的存档日志自动传输到备用数据库中。备用数据库将重新与主数据库同步，而无需管理员的任何手动干预。

简单的集中式管理

Data Guard Broker 使一个 Data Guard配置中的多个数据库间的管理和操作任务自动化。Broker 还监控单个 Data Guard配置内的所有系统。管理员可以使用 Oracle Enterprise Manager或 Broker 自己专用的命令行界面(DGMGRL)来利用这个集成的管理框架。

与 Oracle 数据库集成

Oracle Data Guard 是作为 Oracle数据库（企业版）的一个完全集成的功能提供的，无需任何额外费用。

ORACLE DATA GUARD 进程结构

如下图所示，OracleData Guard使用 Oracle 数据库例程的几个进

程来实现灾难恢复和高可用性所必需的自动化。

在主数据库上，OracleData Guard使用日志写入器进程 (LGWR) 或归档器进程 (ARCH)收集事务重做数据，并将其传输到备用数据库中；使用获取存档日志进程 (FAL)提供一个客户服务器机制，用于在主数据库和备用数据库之间出现通信中断之后将存档日志发送到备用数据库中，以实现自动填充间隔和重新同步。

在备用数据库上，Oracle Data Guard使用远程文件服务器 (RFS)进程从主数据库接收重做记录；

使用管理恢复进程 (MRP)将重做信息应用到物理备用数据库中；

使用逻辑备用进程 (LSP)将经过 SQL转换的重做信息应用到逻辑备用数据库中。

主要技术组件

Data Guard 配置

一个 Data Guard配置包括一个主数据库和最多九个备用数据库。主数据库和备用数据库可以运行在单个节点上或一个真正应用集群 (RAC)环境中。备用数据库使用 Oracle 网络服务通过基于 TCP/IP的标准网络（如局域网 (LAN)、城域网 (MAN)、广域网 (WAN)）连接

到主数据库。对数据库所处位置没有限制，只要它们能互相通信就行。不过，对于灾难恢复，建议将备用数据库装载在地理上与主站点隔开的站点上。

Data Guard 要求主系统和备用系统上的操作系统结构相同。因此，如果主数据库是在 Intel结构上运行 Linux 操作系统，则其所有备用数据库也必须在 Intel结构上运行 Linux 操作系统—例如，它们不能是 Windows系统。此外，必须在一个 Data Guard 配置中的主数据库和所有备用数据库上安装相同版本的 Oracle数据库企业版。

重做应用和 SQL 应用

备用数据库最初是从主数据库的一个备份副本创建的。一旦创建了备用数据库，Data Guard自动将主数据库重做数据传输给备用系统，然后将重做数据应用到备用数据库中，从而使备用数据库保持为与主数据库在事务上一致的副本。

Data Guard 提供了两种方法将这些重做数据应用到备用数据库中，并使之与主数据库在事务上保持一致。这些方法与Data Guard支持的两种类型的备用数据库对应：

•  重做应用，用于物理备用数据库

•  SQL应用，用于逻辑备用数据库

请注意，如图 2 所示，就从主数据库进行的数据传输而言，这两种类型的备用数据库之间没有差别。一旦重做数据到达备用服务器，这两种类型的备用数据库在将重做数据应用到备用数据库的方式上就存在差异了。

物理备用数据库—重做应用通过使用 Oracle介质恢复应用从主数据库接收到的重做数据，物理备用数据库与主数据库保持同步。它在物理上与主数据库逐块相同，因而数据库模式（包括索引）是相同的。

 重做应用如何工作

主数据库上的一个日志切换将触发备用数据库上的一个日志切换，从而使备用数据库上的归档器进程将当前的备用重做日志文件归档到备用数据库上的一个存档日志中。随后，Data Guard重做应用使用一个专用进程（称为管理的恢复进程 (MRP)）读取存档日志，并将重做数据应用到物理备用数据库中。如果启用了Oracle Database10g中的 OracleData Guard的新功能—实时应用，则 MRP将在 RFS进程写满当前的备用重做日志文件时直接从其中读取重做数据。通过加载物理备用数据库并使用以下命令，可以在该数据库上启动 MRP（从而应用重做数据）：

ALTER DATABASE RECOVER MANAGED STANDBYDATABASE DISCONNECT FROM SESSION;

介质恢复进程可以并行运行，以获得 Data Guard重做应用的最佳性能。在 Oracle Database 10g之前的版本中，这需要在上述 RECOVER MANAGED STANDBY DATABASE命令中使用 PARALLEL 子句。在 Oracle Database10g中，MRP可以在启动（无需 PARALLEL 子句）时自动确定并行恢复进程的最佳数量，这个数字视备用服务器上可用的 CPU数量而定。

物理备用数据库可以以只读方式打开，并且可以在其打开时对其运行查询，但无法在其以只读方式打开的同时运行恢复。在备用数据库以只读方式打开时，传送给它的重做数据将在备用站点上累积而不应用。

不过，可以随时在物理备用数据库上恢复操作，并自动应用累积的重做数据。这允许物理备用数据库以一个序列运行，这个序列可能包括在恢复中运行一段时间，然后以只读方式打开来运行报表，接着重新运行恢复来应用尚未应用的重做数据。要以只读方式打开物理备用数据库，则需使用以下命令在备用数据库上取消恢复：

 

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

然后可以只读方式打开数据库：

ALTER DATABASE OPEN;

物理备用数据库的好处

物理备用数据库提供了以下好处：

灾难恢复和高可用性

   物理备用数据库实现了一个健全而高效的灾难恢复和高可用性解决方案。易于管理的转换和故障切换功能允许主数据库和物理备用数据库之间的简单角色转换，从而使主数据库因计划的和计划外的中断所导致的停机时间减到最少。

数据保护

使用物理备用数据库，DataGuard可确保即使在遇到不可预见的灾难时也不会丢失数据。物理备用数据库支持主数据库支持的所有数据类型以及 DDL和 DML 操作。它还提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传播到备用数据库上。同样，导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后，在将重做数据应用到备用数据库时对其进行验证。

减少主数据库的工作负载

可以以只读方式打开物理备用数据库，来生成报表和进行查询。此外，利用恢复管理器 (RMAN)，可以利用物理备用数据库来为生产数据库创建备份，从而从生产系统中节省宝贵的 CPU周期和 I/O 周期。RMAN可以在物理备用数据
性能

物理备用数据库所用的重做应用技术使用低级恢复机制来应用更改，这种机制绕过了所有 SQL级代码层，因此是最有效的应用更改机制。这使得重做应用技术成为一种在数据库之间传播更改的极其有效的机制。

逻辑备用数据库

尽管数据的物理组织和结构可能不同，但逻辑备用数据库包含与主数据库相同的逻辑信息。SQL应用技术将从主数据库接收到的重做数据转换成 SQL语句，然后在备用数据库上执行 SQL语句，以使逻辑备用数据库与主数据库保持同步。从而，在将 SQL应用到逻辑备用数据库上的同时，可以访问逻辑备用数据库来进行查询和报表操作。由于使用 SQL语句更新逻辑备用数据库，因此它保持以读写模式打开，而从主数据库中更新的表可以同时用于诸如报表、合计、查询等他任务如。还可通过在维护的表上创建额外的索引和物化视图来优化这些任务。逻辑备用数据库可以承载多个数据库模式，用户可以对这些模式中不从主数据库进行更新的表上执行普通的数据处理操作。

逻辑备用数据库对数据类型、表的类型以及 DDL和 DML操作的类型有一些限制。有关这些不支持的数据类型和存储属性，请参见 [1]。SQL应用如何工作SQL 应用使用许多并行的执行服务器和后台进程，它们将来自主数据库的更改应用到逻辑备用数据库中。下图显示了信息流和每一个进程所起的作用。

这些不同的 SQL 应用进程可以通过在逻辑备用数据库上输入这条简单的命令来启动：

ALTER DATABASE START LOGICAL STANDBY APPLY;

出于每个 SQL 应用进程的考虑，

读取器进程从存档日志（如果启用了实时应用，也可以是备用重做日志，）中读取重做记录。

准备器进程将块更改转换成表更改或逻辑更改记录 (LCR)。在这里，LCR并不代表任何特定的事务。

构造器进程对来自各个 LCR的已完成事务进行组合。

分析器进程检查完成的事务，辨明不同事务之间的相关性。

协调器进程（也称为逻辑备用进程，即 LSP）负责将事务分配给应用进程、监控事务之间的相关性以及批准将更改提交给逻辑备用数据库。

应用器进程将已指定事务的 LCR应用到数据库中，并在协调器指示提交事务时提交。Data Guard 提供视图来帮助查看每个进程的状态。

逻辑备用数据库的好处

逻辑备用数据库提供了与物理备用数据库类似的灾难恢复、高可用性和数据保护的好处。它还提供了以下特有的好处：

有效利用备用硬件资源

逻辑备用数据库除了可满足灾难恢复要求外，还可满足其他业务需求。它可以承载除在Data Guard配置中受保护的模式之外的其他数据库模式，并且用户可以随时在这些

模式上执行 DDL 或 DML 操作。由于可以将受Data Guard保护的逻辑备用表存储在一个与主数据库不同的物理布局中，因此可以创建额外的索引和物化视图来提高查询性能并满足特定的业务要求。

减少主数据库工作负载

逻辑备用数据库可以在保持打开的同时从主数据库中更新它的表，这些表可同时用于只读访问。这使得逻辑备用数据库能够同时用于数据保护和报表操作，从而将那些报表和查询任务从主数据库上解除下来，节约宝贵的 CPU周期和 I/O周期。

实时应用

利用 Oracle 数据库 10g 中的 Data Guard的实时应用新特性，可以在将重做数据一写到备用重做日志 (SRL)中时，就将重做数据应用到备用数据库中（无论采用重做应用还是或 SQL应用）。Data Guard的早期版本要求，先在备用数据库中归档重做数据，才能以存档日志的形式应用重做数据。要启用物理备用数据库的实时应用，应使用以下命令在物理备用数据库上启动恢复：

ALTER DATABASE RECOVERMANAGED STANDY DATABASE USING CURRENT LOGFILE;

要启用逻辑备用数据库的实时应用，应使用以下命令在逻辑备用数据库上启动应用进程：

ALTER DATABASE STARTLOGICAL STANDBY APPLY IMMEDIATE;

实时应用特性允许备用数据库与主数据库保持密切同步，从而启用最新和实时报表（特别用于 Data Guard SQL应用）.

同时，这一特性也可减少转换时间和故障切换时间，进而降低计划内和计划外业务停机时间。灾难的影响通常根据恢复点目标

（RPO —即在出现灾难时，业务可以经受得住丢失多少数据）和恢复时间目标

（RTO —即在出现灾难时，业务可以经受得住停机多长时间）来衡量。使用Oracle Data Guard，当结合使用最大保护模式（确保即使在出现灾难时也不会丢失数据）和实时应用时，企业在出现灾难时不仅获得了零数据丢失的好处，同时还获得了最少停机时间的好处，这使得Oracle Data Guard 成为当今唯一为业务提供最佳 RPO 和 RTO好处的解决方案。

数据保护模式

Oracle Data Guard 提供三种高水平的数据保护模式来平衡成本、可用性、性能和事务保护。可以使用任意可用管理界面来轻松地设置这些模式。例如，下面是一条简单的 SQL语句，在主数据库上执行此语句可实现此目的：

ALTER DATABASE SET STANDBYDATABASE TO MAXIMIZE {PROTECTION | AVAILABILITY | PERFORMANCE};

要确定适当的数据保护模式，企业需要根据用户对系统响应时间的要求来估量它们对数据保护的业务要求。下表从数据丢失风险的角度概述了各种模式的适用性。

保护模式

在出现灾难时数据丢失的风险

重做传输机制

最大保护

零数据丢失；双重故障保护

LGWR SYNC

最高可用性

零数据丢失；但故障保护

LGWR SYNC

最高性能

最小数据丢失通常0到几秒

LGWR SYNC 或ARCH

最大保护

最大保护模式为主数据库提供了最高水平的数据保护，从而确保了一个全面的零数据丢失灾难恢复解决方案。

当在最大保护模式下运行时，重做记录由日志写入器进程从主数据库同步地传输到备用数据库，并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时，才在主数据库上提交事务。

这种模式必须配置至少两个备用数据库，从而提供双重故障保护。当最后参与的备用数据库不可用时，主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时，不会丢失事务。由于重做传输的同步特性，这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

最高可用性

最高可用性模式拥有仅次于最高水平的主数据库数据可用性，并提供零数据丢失和防止单组件故障。

如同最大保护模式一样，重做数据由日志写入器进程从主数据库同步地传输到备用数据库，直到确认事务数据在备用服务器的磁盘上可用时，事务才在主数据库上完成。

不过，在这种模式下（与最大保护模式不同），如果最后参与的备用数据库变为不可用—例如由于网络连接问题，处理将在主数据库上继续进行。备用数据库与主数据库相比，可能暂时落在后面，但当它再次变为可用时，备用数据库将自动同步，而不会丢失数据。由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。

最高可用性模式适用于想要在生产站点上出现严重中断时（假定没有其他故障）确保获得零数据丢失保护，但不想让生产数据库受网络/备用服务器故障影响的企业。

最高性能

最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。在这种模式下，当主数据库处理事务时，重做数据由日志写入器进程异步传输到备用数据库上。另外，也可以将主数据库上的归档器进程配置为在这种模式下传输重做数据。在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。不过在这种情况下，数据库告警日志将记录错误消息，并可以通过Enterprise Manager 相应地设置告警。

在主数据库出现故障的情况下，可能有一些在主数据库上提交了的事务没有传输到备用数据库中。如果网络有足够的吞吐量来跟上重做流量高峰，则丢失的事务将非常少或者为零。

当主数据库上的可用性和性能比丢失少量数据的风险更重要时，应该使用最高性能模式。这种模式还适合于 WAN上的Data Guard 部署，在 WAN中，网络的内在延迟可能限制同步重做传输的适用性。

故障切换和转换

Oracle Data Guard 提供了两种易于使用的方法来处理生产站点的计划内停机和计划外中断。这些方法称为转换和故障切换。管理员可以使用 Oracle Enterprise Manager GUI界面、Data Guard Broker 的命令行界面或直接通过SQL来轻松地启动这些方法。

故障切换是在主数据库上出现计划外的灾难性故障，且不可能及时恢复主数据库时，将一个联机的备用数据库用作新的主数据库的操作。故障切换操作在将承担主数据库角色的备用数据库上启动。如果在故障恢复之前在原来的主数据库上启用了Oracle Database 10g的闪回数据库功能，并且打算将原来的主数据库恢复为 Data Guard 配置中的一个新的备用数据库，则可以在故障恢复之后使用此功能。如果在故障切换之前没有启用闪回数据库，而需要在故障切换之后将原来的主数据库恢复为一个备用数据库，则必须从新主数据库的一个备份副本重新创建该备用数据库。                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              

下图显示了从一个位于旧金山的主数据库向一个位于波士顿的物理备用数据库进行故障切换操作的结果。

相反，转换选项是主数据库和备用数据库之间计划的角色转换，用于处理主数据库上的计划维护。

转换操作和故障切换操作之间的主要差异是，转换是在主数据库仍然可用时进行，且不需要闪回或重新安装原来的主数据库。这允许原来的主数据库几乎立即承担起备用数据库的角色。因而，可以更轻松、更频繁地执行计划维护。例如，当主站点上升级硬件时，转换功能通过将所有数据库客户机转换到备用站点，以在主站点上执行升级。有时，术语“转回”(switchback)也可在Data Guard 角色管理范围中使用。转回操作只不过是将角色恢复到其原来状态的后续转换操作。

转换操作始终确保在转换期间不会丢失数据。如果Data Guard运行在最大保护模式或最高可用性模式下，故障切换操作确保在故障切换时不会丢失数据。应当强调的是，为了避免在出现临时系统故障或网络故障的情况下进行错误的故障恢复/转换，Data Guard转换和故障恢复操作不是自动进行的，而必须由管理员明确启动。一旦启动，Data Guard就自动运行相关的进程。当配置中包含多个备用数据库时，故障切换和转换操作可以无缝地进行。例如，如果在配置了多个备用数据库的情况下主数据库出现故障，则管理员可以灵活地选择一个可用的备用数据库，使其成为主数据库。

Data Guard 使重定向其他备用数据库来使用新主数据库的过程（包括传输任意丢失或不完整的重做数据）完全自动化。自动重新同步 Oracle Data Guard可以顺畅地处理将备用（物理或逻辑）数据库与主数据库暂时断开的网络连接问题。

 当备用数据库变为不可用时（除非这个备用数据库是最大保护模式下的最后一个可用的备用数据库，在这种情况下主数据库将关闭），则在主数据库本地捕获事务。当重新建立与备用数据库的连接时，将自动传输累积的存档日志，并将其应用到备用数据库中，直到备用数据库已经与主数据库重新同步。这个过程不需要任何管理干预。Oracle建议，如果在主站点附近经常发生网络中断，则网络容量应足够处理这种重新同步。

人为错误保护

当主数据库打开并处于活动状态时，事务处理正在进行，生成重做数据，并将其传输到备用站点上。鉴于人为错误是造成系统停机的主要原因，这种重做数据可能包含重大的逻辑用户错误，如丢失一个重要的表，这可能使主数据库崩溃。

Data Guard 提供了几种易于使用的方式来避免这种用户错误。管理员可以决定在主数据库和备用数据库上同时使用Oracle Database 10g的闪回数据库功能，以快速将数据库恢复到一个较早的时间点上，从而取消这种用户错误。另外，如果管理员决定故障切换到一个备用数据库上，但那些用户错误已经应用到了备用数据库中（例如，由于启用了实时应用），则管理员可以简单地将备用数据库闪回到一个安全的时间点上（假定在备用数据库上已经启用了闪回功能）。最后，管理员还有额外的选择，可以不在一个或多个备用数据库上使用实时应用特性，相反使重做数据在那些备用数据库上的应用延迟一段可配置的时间，这提供了一个防止这种用户错误或损坏的保护窗口。不管选择哪个选项，备用数据库上的应用进程将始终重新验证日志记录，以防止将物理重做数据损坏应用到备用数据库上。

通过闪回数据库的功能解决用户的误操作，通过关闭实施应用特性避免这种情况的发生。

滚动升级

通过使用 DataGuard SQL应用，Oracle Database 10g 支持数据库软件以滚动的方式进行升级（从Oracle Database 10g开始），在此方式下，数据库宕机时间几乎为零。这些步骤包括将逻辑备用数据库升级到下一个版本、在一种混合的模式下运行，以测试和验证升级、通过切换到已升级的数据库来执行角色转换，然后最终升级旧的主数据库。当为了测试而运行在一种混合模式下时，可以终止升级，并且软件降级，而不会有数据丢失。为了在这些步骤中提供额外的数据保护，可以使用第二个备用数据库。通过支持具有最小停机时间的滚动升级，Data Guard缩小了一般包含许多管理任务的大维护窗口，并实现了 24x7 的业务运转。

级联重做日志目标

在这种情况下，一个备用数据库是从另一个备用数据库而非原始主数据库接收重做数据。因为主数据库仅将重做数据发送给备用数据库的一个子集，所以这一特性减少了主系统上的负载，并且还减少了主站点周围的网络流量和对宝贵的网络资源的使用。

Enterprise Manager 和Data Guard Broker

Oracle Data Guard Broker 是一个分布式管理框架，它不但自动化了 DataGuard 配置的创建、维护和监控，并对这些操作进行统一管理可以通过 Oracle Enterprise Manager（它使用 Broker）或 Broker的专用命令行界面(DGMGRL) 执行所有管理操作。下面这张屏幕截图显示了 Enterprise Manager的 Data Guard 主页。

以下列表说明了Broker 自动化和简化的一些操作：

•  创建和启用 Data Guard配置，此配置包括一个主数据库和最多九个备用（物理或逻辑）数据库，这些数据库的全部或某个组合可形成 RAC集群。

•  从配置中的任意站点上管理整个 DataGuard配置。

•  执行转换或故障切换操作，此类操作涉及到配置中的所有系统的复杂角色转换。

•  利用集中式监控、测试和事件通知，来监控日志使用率、捕获诊断信息并快速检测问题。Broker的易于使用的界面和对 Data Guard 配置的集中管理和监控使Data Guard成为企业获得增强的高可用性和数据保护的解决方案。

配置选项

备用数据库可以是远程（通过WAN或 MAN 连接）或本地的（在 LAN上连接）。一个 Data Guard 配置可以包括本地和远程备用数据库，并可配置为提供这两种方法的好处。Oracle Data Guard—以最低的成本实现最大的数据保护  第 18页因为一个使主数据库停机的事件不可能也使备用数据库停机，所以远程备用数据库是灾难恢复的最佳解决方案。但是，较高的延迟可能影响性能。本地备用数据库比较适合解决数据中心内与人为错误或数据损坏相关的中断。因为 LAN提供了低延迟、便宜、可靠的网络链路，所以专门分配一个 LAN 网段用于备用可为最大保护模式提供一个理想环境。关于 Data Guard网络配置最佳应用建议，请参见 [5]。

ORACLE DATA GUARD 和 RAC

Oracle Data Guard 和 Oracle真正应用集群 (RAC) 彼此互补。RAC解决系统或例程故障。它提供不影响数据的故障（如节点故障或例程崩溃）的快速和自动恢复。它还为应用程序提供增强的可伸缩性。

另一方面，DataGuard 通过使用在事务上一致的主数据库和备用数据库

—它们既不共享磁盘也不运行在锁步模式下

 —提供数据保护。这使得从站点灾难或数据损坏中恢复成为可能。

 

DataGuard还生来就与 RAC集成

—例如，一些或所有主/备用（物理或逻辑）数据库可以是 RAC数据库，并且可以使用 Enterprise Manager、Broker的命令行界面或直接使用 SQL 来管理这些数据库。

客户应当把 Oracle Data Guard和真正应用集群结合使用来获得数据级和系统级保护的好处。

最高可用性结构

随着有更多的系统功能可以使用，IT经理、设计师和管理员常常发现，集成一套合适的特性来构建满足其所有业务要求的一个统一的高可用性 (HA)解决方案非常困难。Oracle最高可用性结构 (MMA)是 Oracle的最佳实践方案。它基于验证过的 Oracle高可用性技术和标准，其目标是消除设计最优高可用性结构时的复杂性，并使系统可用性最大化。

MAA 提供了以下好处

（1）降低了高可用性Oracle系统的实施成本

通过提供详细的配置准则，MAA降低了一个高可用性 Oracle系统的实施成本。突出显示了对不同配置的性能影响研究结果，以确保选定的高可用性结构可以持续地运行并根据业务需求进行伸缩。

（2）提供最佳方案和恢复步骤消除最小化的异常中断宕机的时间

MAA 提供了最佳方案和恢复步骤，来消除或最小化可能因正常和异常中断（如人为错误、系统故障和崩溃、维护、数据故障、损坏以及灾难）而出现的宕机时间。

（3）控制中断的时间出现灾难可接受的数据丢失量

MAA 可控制中断的恢复时间以及出现灾难时的可接受数据丢失量，从而允许调整平均恢复时间 (MTTR)，以适应特定的业务要求。

Data Guard 是 MAA的基本组件，MAA 准则包括有关 Data Guard配置各个方面（如涉及 RAC 和 Data Guard的配置、重做数据传输机制、转换/故障切换、介质恢复、SQL应用配置、网络配置等）的最佳实践标准（参考文献 [3] –[6]）。强烈推荐对 Data Guard实施感兴趣的客户参考这些 MAA 最佳实践准则。除 MAA白皮书外，还为对Oracle 数据库 10g感兴趣的客户提供了有关高可用性最佳实践的标准化 Oracle 文档（参考文献 [2]）。

DATA GUARD 和远程镜像解决方案

远程镜像解决方案从概念上看好像是要提供简单而完善的数据保护。然而，在数据保护方面，Oracle Data Guard在本质上要比远程镜像解决方案更有效、更便宜、更优化。客户不需要购买远程镜像解决方案或将远程镜像解决方案与Oracle Data Guard集成。下面是与远程。

镜像解决方案相比的好处

更高的网络效率

使用 OracleData Guard，只需将重做数据发送到远程站点上。然而，如果使用远程镜像解决方案进行数据保护，则必须为数据库文件、在线日志、存档日志和控制文件创建镜像。这意味着远程镜像将把每次更改至少三次发送到远程站点上。此外，数据库写操作将比日志写操作更频繁地发生，这是因为每次日志写操作一般包含许多更改（称为组提交）。这意味着一个基于数据库重做传输的解决方案所需的网络带宽要比一个远程镜像解决方案少得多。更重要的是，这意味着少得多的网络回程。

远程镜像对于非数据库文件可能非常有用，但对于数据库数据

—更好的保护和更低成本的结合是使用 Data Guard的令人信服的原因。对 Oracle 的企业电子邮件系统的一个内部分析（如下图所示）说明了与使用 Data Guard相比，使用远程镜像解决方案通过网络传输的数据要多 7 倍，进行的 I/O操作要多 27 倍。

更适合于 WAN

由于存储系统使用的底层通信技术（光纤、ESCON），基于存储系统的远程镜像解决方案通常有距离的限制。可以使用来自第三方供应商的专门设备来扩展这个距离。这些设备将 ESCON/光纤转换成相应的 IP、ATM或 SONET 网络。问题是，每增加一台这种设备，就在系统中引入延迟，从而影响生产数据库的性能，并使得这种配置不适用于零数据丢失功能所必需的同步传输。可以通过在通信路径中引入中间存储盒来减轻这个问题，但这增加了总体成本。另一种解决方案是使用变化的同步传输—然而，在依靠远程镜像解决方案的情况下，除同步数据传输外，其他任何方法均不能保持数据库所处的所有镜像卷的写入顺序。这意味着这种配置不能保证所有时间上的数据一致性，从而使得它们不适合作为 OLTP 数据的数据

保护/灾难恢复解决方案。因为 Data Guard仅将重做数据传输到备用站点上（使用标准 IP 网络），并保持在所有保护模式下的事务一致性（即无论使用同步或异步传输模式），并且不需要昂贵的中间存储盒，所以它是一种更好的、适用于 WAN的 DR 和数据保护解决方案。

更好的恢复能力和数据保护

Oracle Data Guard 进程在它们从主数据库读和写信息时识别数据格式。此外，Oracle Data Guard集成了闪回数据库功能，并且允许延迟应用程序的更改。这些功能防止了许多人为错误和数据损坏的传播与/或对备用数据库的影响。远程镜像没有这种优势—任何无意中对一个重要表的删除都将立即传播给数据库文件的远程副本，从而给该数据库文件的远程副本带来不利影响。

更高的 ROI

使用 OracleData Guard，备用数据库可以只读方式打开，以在更改仍传播时进行报表操作。对于远程镜像解决方案而言，事实并非总是这样。此外，Oracle Data Guard是核心的 Oracle 数据库的一个即取即用的特性。它不会造成额外费用或额外集成。然而，远程镜像解决方案需额外购买，并且需要与数据库进行复杂的集成。最后一点，也是非常重要的一点，许多远程镜像解决方案是专利产品，并且只能与制造这些远程镜像解决方案的同一供应商的存储系统一起使用（在主站点和从站点上）。相反，Data Guard在主站点和备用站点上都不限制使用特别的存储解决方案。

结论

Oracle Data Guard 是为企业提供的一个全面的数据保护、灾难恢复和高可用性解决方案。它提供了一个能够解决计划和计划外中断的灵活、易于管理的框架。物理备用数据库和逻辑备用数据库互相补充，并且可以同时进行维护，从而在减少主数据库上开销的同时提供高品

质的数据保护。不同的数据保护模式提供了适用于各种保护、性能和基础架构需求的灵活性。Data Guard Broker与Oracle Enterprise Manager 的结合提供了一个易于使用的配置和管理框架。