Oracle Dataguard（主库为 Oracle 11g 单节点）配置详解（1）：Oracle Dataguard 概述

Oracle Dataguard（主库为 Oracle 11g 单节点）配置详解（1）：Oracle Dataguard 概述

一、Oracle Dataguard 概念

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

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

二、Oracle Dataguard 基本原理

1、当某次事务更改生产数据库中的数据时，Oracle 在联机重做日志文件（redo log）中记录此次更改。

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

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

3、当备份数据库接收到日志信息时，Dataguard 可以自动利用日志信息实现数据的同步。

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

图1 Oracle Dataguard 结构

三、Oracle Dataguard 的特点

1、需要有冗余的服务器硬件。

2、需要冗余的存储设备，主机和备机都需要同样的存储空间。

3、安装配置较复杂，需要更多的配置步骤。

4、管理与维护成本高，该模式对维护人员的要求较高。

5、具备一定的容灾特性，当主机数据库不可用，可以把数据库系统切换到备机上，具备容灾的功能。

6、备机可以用作只读查询，备机可以切换到只读状态供报表之类的查询操作，减轻主机的压力。

四、Oracle Dataguard 的功能

Oracle Dataguard 包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。

Dataguard 利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。并且将重做数据传输到备用站点上，并应用到备用数据库中，从而使备用数据库与主数据库保持同步。

Dataguard 允许管理员选择将重做数据同步还是异步地发送到备用站点上。

备用数据库的底层技术是 Dataguard 重做应用（物理备用数据库）和 Dataguard SQL 应用（逻辑备用数据库）。

物理备用数据库在磁盘上拥有和主数据库逐块相同的数据库结构，并且使用 Oracle 介质恢复进行更新。逻辑备用数据库是一个独立数据库，它与主数据库包含相同的数据。它使用 SQL 语句进行更新。

Dataguard 简化了主数据库和选定的备用数据库之间的转换和故障切换，从而减少了由计划停机和计划外故障所导致的总停机时间。

为了获得更简便的可管理性，Dataguard 还提供了一个分布式管理框架（称为 Dataguard Broker），它不但自动化了 Dataguard 配置的创建、维护和监控，并对这些操作进行统一管理。管理员可以使用 Oracle Enterprise Manager 或 Broker 自己的专用命令行界面（DGMGRL） 来利用 Broker 的管理功能。

图2 Oracle Dataguard 结构组件

五、Oracle Dataguard 进程结构

Oracle Dataguard 的进程结构如图3所示：

图3 Oracle Dataguard 进程结构

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

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

如果启用了 Dataguard Broker，Oracle Dataguard 还使用 Dataguard Broker Monitor（DMON）进程将主数据库和备用数据库作为一个统一的配置进行管理和监控。

六、重做应用和 SQL 应用

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

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

（1）重做应用，用于物理备用数据库。

（2）SQL 应用，用于逻辑备用数据库。

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

1、物理备用数据库：重做应用

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

重做应用的工作过程：主数据库上的日志切换将触发备用数据库上的日志切换，从而使备用数据库上的归档器进程将当前的备用重做日志文件归档到备用数据库上的一个存档日志中。随后，Dataguard 重做应用使用一个专用进程（称为管理的恢复进程：MRP）读取存档日志，并将重做数据应用到物理备用数据库中。如果启用了实时应用，则 MRP 将在 RFS 进程写满当前的备用重做日志文件时直接从其中读取重做数据。

2、逻辑备用数据库：SQL 应用

尽管数据的物理组织和结构可能不同，但逻辑备用数据库包含与主数据库相同的逻辑信息。SQL 应用技术将从主数据库接收到的重做数据转换成 SQL 语句，然后在备用数据库上执行 SQL 语句，以使逻辑备用数据库与主数据库保持同步。从而，在将 SQL 应用到逻辑备用数据库上的同时，可以访问逻辑备用数据库来进行查询和报表操作。

SQL 应用的工作过程：SQL 应用使用许多并行的执行服务器和后台进程，它们将来自主数据库的更改应用到逻辑备用数据库中。读取器进程从存档日志（如果启用了实时应用，也可以是备用重做日志）中读取重做记录。准备器进程将块更改转换成表更改或逻辑更改记录（LCR）。构造器进程对来自各个 LCR 的已完成事务进行组合。分析器进程检查完成的事务，辨明不同事务之间的相关性。协调器进程（也称为逻辑备用进程，即 LSP）负责将事务分配给应用进程、监控事务之间的相关性以及批准将更改提交给逻辑备用数据库。应用器进程将已指定事务的 LCR 应用到数据库中，并在协调器指示提交事务时提交。

3、实时应用

实时应用可以在将重做数据一写到备用重做日志中时，就将重做数据应用到备用数据库中（无论采用重做应用还是 SQL 应用）。实时应用特性允许备用数据库与主数据库保持密切同步，从而启用最新和实时报表。同时，这一特性也可减少转换时间和故障切换时间，进而降低计划内和计划外业务停机时间。

要启用物理备用数据库的实时应用，应使用以下命令在物理备用数据库上启动恢复：

ALTER DATABASE RECOVER MANAGED STANDY DATABASE USING CURRENT LOGFILE;

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

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

七、Oracle Dataguard 数据保护模式

Oracle Dataguard 提供三种数据保护模式（最大保护、最高可用性、最高性能）来平衡成本、可用性、性能和事务保护。在主数据库上执行下面的 SQL 语
句可用于设置三种数据保护模式：

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

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

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

1、最大保护

最大保护模式为主数据库提供了最高水平的数据保护，从而确保一个全面的零数据丢失的灾难恢复解决方案。当在最大保护模式下运行时，重做记录由日志写入器（LGWR）进程从主数据库同步地传输到备用数据库，并且直到确认事务数据在至少一个备用服务器上的磁盘上可用时，才在主数据库上提交事务。

这种模式必须配置至少两个备用数据库，从而提供双重故障保护。当最后参与的备用数据库不可用时，主数据库上的处理将停止。这就确保了当主数据库与其所有备用数据库失去联系时，不会丢失事务。

由于重做传输的同步特性，这种最大保护模式可能潜在地影响主数据库响应时间。可以通过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

2、最高可用性

最高可用性模式拥有仅次于最高水平的主数据库数据可用性。如同最大保护模式一样，重做数据由 LGWR 从主数据库同步地传输到备用数据库，直到确认事务数据在备用服务器的磁盘上可用时，事务才在主数据库上完成。不过，在这种模式下，如果最后参与的备用数据库变为不可用，处理将在主数据库上继续进行。

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

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

3、最高性能

最高性能模式是默认的保护模式。它与最高可用性模式相比，提供了稍微少一些的主数据库数据保护，但提供了更高的性能。在这种模式下，当主数据库处理事务时，重做数据由 LGWR 进程异步传输到备用数据库上。另外，也可以将主数据库上的归档器进程（ARCH）配置为在这种模式下传输重做数据。

在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收。如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。

不过在这种情况下，数据库告警日志将记录错误消息，并可以通过 Enterprise Manager 相应地设置告警。 在主数据库出现故障的情况下，可能有一些在主数据库上提交了的事务没有传输到备用数据库中。如果网络有足够的吞吐量来跟上重做流量高峰，则丢失的事务将非常少或者为零。