(完整版)OracleDataGuard容灾方案

Oracle数据库异地容灾方案介绍

2008年11月

目录

第一章 需求分析............................................................................................................... 4

1.1 序言...................................................................................................................... 4

1.2 用户现状.............................................................................................................. 4

1.2.1 系统平台................................................................................................... 4

1.2.2 数据库平台............................................................................................... 6

1.3 用户需求.............................................................................................................. 7

1.3.1 日常功能................................................................................................... 7

1.3.2 故障切换................................................................................................... 7

1.3.3 基本要求................................................................................................... 7

1.3.4 性能要求................................................................................................... 8

1.3.5 数据一致性............................................................................................... 9

1.3.6 系统兼容性............................................................................................... 9

1.3.7 高可用性................................................................................................. 10

1.3.8 健壮性要求............................................................................................. 10

1.3.9 设备无关性............................................................................................. 10

1.3.10 管理监控功能........................................................................................11

第二章 Oracle Data Guard介绍 ..................................................................................... 12

2.1 Data Guard实现原理 ......................................................................................... 12

2.2 Oracle Data Guard 优势 .................................................................................... 15

2.3 Data Guard提供的保护模式 ............................................................................. 16

2.4 Data Guard实现方式以及对系统的限制要求 ................................................. 17

2.5 切换方式............................................................................................................ 17

第三章 系统建议方案..................................................................................................... 19

3.1 Data Guard优势 ................................................................................................. 19

3.2 Data Guard运行模式 ......................................................................................... 19

3.3 Data Guard保护模式 ......................................................................................... 20

3.4 Data Guard初始安装步骤 ................................................................................. 20

3.5 用户需求点对点应答........................................................................................ 21

3.5.1 日常功能................................................................................................. 21

3.5.2 故障切换................................................................................................. 22

3.5.3 基本要求................................................................................................. 23

3.5.4 性能要求................................................................................................. 23

3.5.5 数据一致性............................................................................................. 25

3.5.6 系统兼容性............................................................................................. 26

3.5.7 高可用性................................................................................................. 26

3.5.8 健壮性要求............................................................................................. 27

3.5.9 设备无关性............................................................................................. 27

3.5.10 管理监控功能....................................................................................... 28

第一章 需求分析

1.1 序言

在信息时代，数据是企业创造商业价值的生产资料，数据的丢失将为企业带来毁灭性的灾难。据Gartner Group的调查数据表明，在经历过大型灾难或长时间系统停运的公司中，有2/5的公司再也未恢复运行，而在其余的公司中，有1/3的公司在两年内破产。

有句古谚叫“别把鸡蛋放在一个篮子里”。现在的信息系统，各种数据高度集中，“鸡蛋”全放在一个篮里了。一旦出现突然停电、意外死机或者人为破坏，造成数据丢失是不可避免的。面对各种未可预知的灾难，越来越多的企业将容灾备份系统作为企业安全的保障。

银联数据异地灾备项目的目标是保证SF25K上各银行（民生银行贷记卡系统拟迁移至IBM主机，故此次灾备项目暂不考虑；邮储银行贷记卡系统主机为IBM

P570，也不在考虑范围之内）发卡系统的安全，在灾难情况下，最大限度地保护公司资产，减少公司各方面的损失，保证发卡系统的业务连续性。

本方案仅对异地容灾数据库复制软件部分做相应阐述。

1.2 用户现状

1.2.1系统平台

发卡系统运行在一台SunFire E25K企业级服务器上，通过两台Brocade SW4900

SAN交换机与两台企业级存储ST9990、SE9970相连，应用系统核心文件和数据库

数据文件均存放在该存储上，存储系统磁盘采用RAID 1+0方式。

SF25K划分为四个物理分区（Domain），每家银行均使用其中的两个，一个Domain作为生产主机，另一个Domain作为热备主机。Domain操作系统为Solaris 10，数据库系统为Oracle 10.2.0.2 RAC。通过Sun Cluster集群软件，实现了生产机房内的双机热备份，保证了系统的高可用性。此外，在主机端还通过Sun MPXIO多通道负载均衡软件，实现两条光纤通道的负载均衡，进一步避免了单点故障。

以下是发卡系统SAN架构图：

Domain A

SF25K

Domain C

Domain B

Domain D

SW4900

SW4900

V280R

NBU Master Server

SE9970

ST9990

VTL

L180 (2 LTO-3)

通过在主机端使用VxVM 4.1卷管理软件，已建立了同机房数据灾备系统，两台存储SE9970与ST9990之间实现了同步数据复制，达到了以下灾难恢复目标：

 日常工作，保证两台存储的数据实时同步保持一致，所有数据不丢失。

 计划外停机，任一台存储发生灾难，保证数据不丢失，即RPO=0，并确保应用不中断运行，即RTO=0。

生产主机

VxVM Mirror Volume

SE9970

ST9990

1.2.2数据库平台

发卡系统中的数据库系统，是整个生产系统中最关键、最复杂的数据对象，发卡系统的业务运转直接依赖于这些数据的可用性。

为了确保数据库的高可用性，发卡系统数据库使用了Oracle 10g RAC版本10.2.0.2，主、备机两节点的数据库实例同时运行，一旦主节点出现问题，数据库实例无需启停，可迅速将应用系统切换至备节点。

截至到2008年8月底，各数据库实例数据量情况见下表：

实例名

HX

SZ

CR

DE

UC

合计

Archive log数据量（GB）

总数据量（GB）

25

15

93

38

275

446

平均每天

1

1

4.5

1.5

12

20

最大帐单日

4

2

5

5

16

32

高峰期Archive log变化量（MB/s）

0.42

0.20

0.40

0.58

2.95

4.55

1.3 用户需求

银联数据拟为提供外包服务的各银行发卡系统建设异地灾备系统，生产系统位于上海，灾备系统位于北京。主备中心之间采用数据库复制软件进行异步数据复制，以保证生产数据的安全性，满足发卡系统的业务连续性需求。

1.3.1日常功能

 将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；

 灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；

 对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；

 对网络带宽的占用较低。

1.3.2故障切换

 当生产中心的系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。

 灾备中心必须在生产中心不可用6小时之内完成业务接管。

 当生产中心服务器恢复正常后，数据复制系统需要将灾备中心的最新数据反向复制回生产中心，实现业务的恢复。

1.3.3基本要求

 复制软件应满足在单机或RAC环境下，对Oracle在线日志(Online redo log)的捕捉及复制；

 支持Oracle中所有的常用数据类型，如Oracle中的LONG 、LONG RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；

 支持对数据库中常用DDL操作的复制；

 支持事务复制，要求对数据库中较大的事务不会出现过多延迟；

 支持没有PK/UK字段的表的同步。

 数据复制过程可根据需要灵活地进行控制或修改复制的方向，以满足业务需求；

 支持在数据复制过程中对数据正确性进行校验，如正在复制的数据在之前就已经不一致，应提供报警功能，以便及时发现错误，避免错误的扩大；

 提供专用图形化集中管理软件。

1.3.4性能要求

 数据库初始化同步

要求数据库复制软件能够将发卡系统的数据库中已有数据初始化同步到灾备中心数据库。在初始化同步过程中，业务不能停止，但可选择业务量较小时段进行。在解决方案书中要求详细描述初始化数据同步解决方案，以及整个首次同步操作所需要的时间（以100GB数据为标准），并且要求列出整个首次初始化过程中是否需要人为干预，从而可以有效地评估整个首次数据初始化的工作量。

为了保证生产中心日后业务扩展存在更换服务器厂商以及数据库版本等情况，需要注明是否支持异构平台下的首次数据初始化同步，是否支持跨数据库版本之间数据库的初始化同步操作。

 数据复制性能指标

数据复制的性能指标与系统平台、网络带宽、应用系统等因素密切相关，参照下列运行环境：

项目

数据源

目标端

总数据量

每天的日志量

网络带宽

配 置

SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2 RAC

SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2

500GB左右（数据+索引）

每天20GB日志

100M和20M

要求提供相应的性能参数指标：

类别 指标

首次数据库初始化同步时间（20M带宽）

首次数据库初始化同步源端CPU占用

源端CPU占用

目标端CPU占用

源端内存占用

目标端内存占用

复制数据延迟平均值

源端CPU占用

参考值

小于48小时

小于30％

小于5％

小于5％

小于200M

小于200M

10s以内

小于10％

小于10％

10s以内

首次数据库初始化同步时间（100M带宽） 小于10小时

首次数据初始化同步

增量数据同步

（单个复制链路）

业务高峰期对系统的影响 目标端CPU占用

复制数据延迟平均值

1.3.5数据一致性

要求数据库复制软件提供数据库初始化同步、数据恢复后以及日常的数据一致性检查方案，要求方案中详细注明该数据一致性比对方案的特点以及操作复杂度，并可满足如下要求：

 可在应用不停机的情况下，查找和发现不一致的数据；

 一致性检查需要能够进行对象属性、记录条数和记录的字段内容进行一致性检查；

 提供全库的记录级一致性检查时间（以100GB的数据为例）。

 支持不含PK/UK字段的表的一致性检查和修复。请提供在没有PK/UK字段的表中有1000万条记录的比对时间。

对于不一致的数据，需要提供不一致记录详细信息，以便进行精确的修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。

1.3.6系统兼容性

数据库复制软件应支持以下操作系统平台：

 Sun Solaris 9,10

 IBM AIX 5.x

数据库复制软件应支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持异构平台，源端和目标端不同数据库版本；支持Cluster/HACMP和RAC模式，并支持不同操作系统下不同数据库版本之间的复制。

1.3.7高可用性

主系统和备用系统的数据库处于双活状态，以保证在灾难发生前可在两个系统上运行不同类型的应用程序。

数据库复制软件应支持本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可通过Cluster软件接管到其它节点。

1.3.8健壮性要求

数据库复制软件在各种大压力和各种故障情况下不会造成数据复制失败。

 网络故障：长时间中断、短时间中断及网络时断时续情况下的正常复制；

 数据库故障：在目标端数据库故障下， 源端数据库不能受到影响。当目标端数据库修复后，复制软件继续工作；

 服务器硬件故障：在目标端服务器故障下， 源端生产系统不能受到影响，当目标端修复后，复制软件继续工作。

1.3.9设备无关性

独立于任何硬件设备、操作系统和Oracle数据库的不同版本，能够实现不同平台之间数据库的复制。

1.3.10管理监控功能

数据库复制软件需提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时具有完整方便的报警及跟踪机制，方便故障的快速定位和解决。

第二章Oracle Data Guard介绍

容灾系统主要包括数据保护和应用切换两大方面，其中最为重要的是数据保护部分。除了要将这些数据存放在高可用的存储设备上之外，最重要的是这些关键数据应该在异地之间保持一致，以使灾难发生后，系统可以尽快恢复。下面是几种主要的数据保护技术。

实现数据的异地复制，有软件方式和硬件方式两种途径。软件方式，是通过主机端软件来实现，如第三方软件或者数据库厂家提供的远程数据容灾工具来实现业务数据的远程复制。

硬件方式，是基于智能存储系统的控制器的远程拷贝，可以在主、备存储系统之间通过硬件实现复制。

在实际的容灾系统中，由于系统的环境不同，安全性要求不同以及采用的软硬件产品不同，数据复制过程中的工作机制也不尽相同。概括地讲，数据复制地工作机制主要包括同步和异步两种。同步远程镜像(同步复制技术)是指通过远程镜像软件，将本地数据以完全同步的方式复制到异地，每一本地的I/O事务均需等待远程复制的完成确认信息，方予以释放。异步远程镜像(异步复制技术)保证在更新远程存储视图前完成向本地存储系统的基本I/O操作，而由本地存储系统提供给请求镜像主机的I/O操作完成确认信息，远程的数据复制以后台同步的方式进行。因为带宽等因素限制，本次容灾方案仅包括了异步复制的方式的讨论。

2.1 Data Guard实现原理

Oracle Data Guard 是当今保护企业核心资产（数据）的最有效解决方案，它能够使数据在 24x7 的基础上可用，而无论是否发生灾难或其它中断。

Oracle Data Guard 是管理、监控和自动化软件的基础架构，它创建、维护和

监控一个或多个备用数据库，以保护企业数据结构不受故障、灾难、错误和崩溃的影响。

Data Guard 使备用数据库保持为与生产数据库在事务上一致的副本。这些备用数据库可能位于距生产数据中心数千公里的远程灾难恢复站点，或者可能位于同一城市、同一校园乃至同一建筑物内。当生产数据库由于计划中断或意外中断而变得不可用时，Data Guard 可以将任意备用数据库切换到生产角色，从而使与中断相关的停机时间减到最少，并防止任何数据丢失。

作为 Oracle 数据库企业版的一个特性推出的 Data Guard 能够与其它的

Oracle 高可用性 (HA) 解决方案（如真正应用集群 (RAC) 和恢复管理器 (RMAN)）结合使用，以提供业内前所未有的高水平数据保护和数据可用性。下图提供了

Oracle Data Guard 的一个概述。

Oracle Data Guard 包括一个生产数据库，也称为主数据库，以及一个或多个备用数据库，这些备用数据库是与主数据库在事务上一致的副本。Data Guard 利用重做数据保持这种事务一致性。当主数据库中发生事务时，则生成重做数据并将其写入本地重做日志文件中。通过 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 的管理功能。

下图显示了 Oracle Data Guard 组件。

太极计算机股份有限公司

2.2 Oracle Data Guard 优势

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

完善的数据保护 — 使用备用数据库，Data Guard 可保证即使遇到不可预见的灾难也不会丢失数据。备用数据库提供了防止数据损坏和用户错误的安全保护。主数据库上的存储器级物理损坏不会传播到备用数据库上。同样，导致主数据库永久损坏的逻辑损坏或用户错误也能够得到解决。最后，在将重做数据应用到备用数据库时会对其进行验证。

有效利用系统资源 — 备用数据库表使用从主数据库接收到的重做数据进行更新，并且可用于诸如备份操作、报表、合计和查询等其它任务，从而减少执行这些任务所必需的主数据库工作负载，节省宝贵的 CPU 和 I/O 周期。使用逻辑备用数据库，用户可以在模式中不从主数据库进行更新的表上执行数据处理操作。逻辑备用数据库可以在从主数据库中对表进行更新时保持打开，并可同时对表进行只读访问。最后，可以在维护的表上创建额外索引和物化视图，以获得更好的查询性能和适应特定的业务要求。

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

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

自动间隔检测及其解决方案 — 如果主数据库与一个或更多个备用数据库之间的连接丢失（例如，由于网络问题），则在主数据库上生成的重做数据将无法发送到那些备用数据库上。一旦重新建立连接，Data Guard 就自动检测丢失的存档日志序列（或间隔），并将必要的存档日志自动传输到备用数据库中。备用数据库将重新与主数据库同步，而无需管理员的任何手动干预。

简单的集中式管理 — Data Guard Broker 使一个 Data Guard 配置中的多个数据库间的管理和操作任务自动化。Broker 还监控单个 Data Guard 配置内的所有系统。管理员可以使用 Oracle Enterprise Manager 或 Broker 自己

太极计算机股份有限公司

专用的命令行界面 (DGMGRL) 来利用这个集成的管理框架。

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

2.3 Data Guard提供的保护模式

Oracle针对用户的不同需求提供三种保护模式：最大保护模式、最大性能模式、最大可用模式。

Oracle提供的Data Guard在最大保护模式下可以确保数据完全不丢失。它在写本地日志的同时写远程standby的数据库日志。只有两个日志均写成功后一个操作才是正式完成。这种方式确保了数据的最大安全，能够确保主数据库损坏的情况下没有任何数据丢失。但这种情况对主数据库性能有较大的影响，即使在高速的局域网内，最大保护模式也会对主数据库性能有超过10%的性能影响。这种方式对主备两个数据库之间的链路有非常高的要求。在这种保护模式下无论是网路链路还是standby数据库等发生故障导致日志无法正常写均会导致主数据库无法使用。因此只有在对数据安全要求最高的情况下才会考虑使用这种方式。

Oracle也提供最大性能模式。这种模式下，不传输实时修改的日志文件，传递的是归档日志文件，因此对主数据库性能影响很小。归档日志文件传递是否能够成功对主数据库运行没有任何影响，因此在网络出现中断或者standby数据库出现异常也不会影响主数据库的正常运行。但因为日志没有同步写，因此在灾难发生的时候备份数据库与主数据库可能有一定的数据差异。

Oracle提供的第三种模式是上述两种方式的折中。在网络正常的情况下它的运行方式类似于最大保护模式，日志实时传递。当网络或standby出现故障的时候它的运行模式类似于最大性能模式，日志延迟传递，不会导致主数据库停止运行。这种方式在正常情况下因为日志实时传递，因此同样对主数据库性能有较大影响，而且对网络链路要求较高。

综上所述，不同的保护模式比较如下：

对主数据库性能影响

对网络链路要求

最大保护

较高

极高

最大可用

较高

高

最大性能

低

低

太极计算机股份有限公司

备份系统发生故障

数据保护

主数据库不可用

无数据丢失

无影响

基本无数据丢失

无影响

少量数据丢失

2.4 Data Guard实现方式以及对系统的限制要求

Oracle针对不同的用户情况提供的两种不同的standby方式。物理standby ,逻辑standby。

物理standby数据库，在通常的模式下备份库始终处于恢复状态，用户无法访问备份库的数据。如果需要访问数据，需要将恢复模式停止，将数据库打开到只读状态。这两种状态是排它的，也就是说数据库要么是恢复状态，保持和主数据库一致，在这种状态下数据库内容不可访问；要么是只读状态，数据库不会做恢复与主数据保持一致。

Oracle还提供逻辑standby数据库。这种方式下数据库可以在打开的状态下保持与主数据库的同步工作。这种打开状态和普通的数据库open状态不同，不能对数据做修改。这种方式通常用于繁忙的系统，如主数据库日常完成业务处理，逻辑standby数据库在完成容灾的同时分担主数据库的查询统计工作。这样大大节约了系统资源。但这种方式对数据库有一定的限制，并不是所有的系统都能够支持。部分较为特殊的数据类型不支持，另外所有的表必须要有主键或者唯一性索引。

无论是物理standby 还是逻辑standby均对系统要求如下:

 主备数据库必须是完全相同的硬件架构，如均为SUN平台。机器的内存大小、CPU数量主频可以不同。

 操作系统版本、补丁完全相同。

 数据库版本完全相同。但RAC选件可以不同。即主数据库可以是RAC模式，备份节点可以是单机。

2.5 切换方式

Oracle Data Guard可以实现failover 以及switchover的切换。

Switchover指有计划的切换。如系统主数据库服务器需要硬件维护等有计划的停机操作。这时候可以手工将所有的日志以及归档日志文件传输到备份节点

太极计算机股份有限公司

后执行switchover的切换。这种情况下等主数据库恢复正常后系统可以手工切换回来。

Failover切换是指系统出现了异常情况下的切换。系统管理员发现主数据库服务器无法提供服务，决定启动容灾系统。在这种情况下的切换后如果主数据库服务器恢复正常后需要重新配置整个Data Guard环境，无法切换回主数据库服务器。

无论是那种切换方式，主备系统之间均存在部分差别。如IP地址不同，需要修改服务器IP 地址或应用程序重新指向。因为在不同的局域网内，应用中间件需要跨防火墙访问系统。机器档次不同、网络带宽不同造成的性能下降等问题。这需要在容灾的预案中考虑。

太极计算机股份有限公司

第三章 系统建议方案

针对本容灾方案，我们推荐采用Oracle Data Guard技术。

3.1 Data Guard优势

 节约投资

Oracle Data Guard是Oracle原厂自带的容灾产品。该产品完全免费。在容灾软件上用户无需支付额外费用，这可以大大节约用户的资金投入。

 技术成熟、稳定

早在Oracle 7版本就已经推出该功能（当时名称为Standby数据库）。其核心采用了Oracle成熟的归档、备份、恢复技术。经过多年不断的发展，已经成为一项技术成熟、稳定，有广泛成功案例的技术。

 对系统运行性能影响小

Data Guard在主数据库服务器端不存在对日志解析等工作，仅需要主数据库服务器端将归档日志文件传输到容灾节点。因此对生产系统性能影响极小。

 能够满足用户基本业务需求

Data Guard能够满足用户基本的数据容灾、RTO、RPO、带宽等相关基本业务需求。

3.2 Data Guard运行模式

Oracle提供了物理Data Guard以及逻辑Data Guard两种不同的方式。这两种方式各有优缺点。因为用户数据库中存在大量表，这些表没有PK/UK；因此无法满足逻辑Data Guard的使用前提条件。在本方案中，我们推荐采用物理Data

Guard的方式。

太极计算机股份有限公司

3.3 Data Guard保护模式

根据用户的实际情况，在主数据库服务器和容灾数据库服务器之间距离较远，使用最大保护模式和最大可用模式均会严重影响主数据库的运行性能。用户允许在出现异常情况下15分钟内的数据丢失量，因此采用最大性能模式可以在现有带宽的情况下满足用户的容灾需求。

采用最大性能模式，系统不会实时传输日志文件，传递的是归档日志文件，因此对主数据库性能影响很小。归档日志文件传递是否能够成功对主数据库运行没有任何影响，因此在网络出现中断或者standby数据库出现异常也不会影响主数据库的正常运行。但因为日志没有同步写，因此在灾难发生的时候备份数据库与主数据库可能有一定的数据差异。

3.4 Data Guard初始安装步骤

1、确认主数据库运行于归档模式

如果主数据库没有处于归档模式，那么需要将数据库运行模式修改为归档模式。该修改过程需要短暂停止数据库运行。

2、物理备份主数据库的所有数据文件

该部分工作可以在不影响业务正常运行的情况下执行。该部分工作依据数据量以及I/O速度不同，所需要的时间也不同。一般估算，100G的数据应在1小时内备份完成。该备份操作启动后无需人为干预。

3、在主数据库创建standby 控制文件

通过命令创建灾备中心的控制文件。

4、拷贝备份的数据文件、standby控制文件及日志文件到备份节点。

因为数据量较大，可以将备份的文件压缩后传递。100G的备份文件经压缩，通常压缩率在40% - 50%之间。100G文件压缩后约50G。在网速为20M带宽的情况下，假设网络利用率为70%，那么速度约为6G/每小时；50G的文件需要9个小时传递完成。在网速为100M带宽的情况下，假设网络利用率为70%，那么速度约为30G/每小时；50G的文件需要1.5个小时传递完成。在数据传输启动后无需人为干预。

太极计算机股份有限公司

5、配置主、备中心的数据库服务器Data Guard环境

该操作对主数据库运行没有任何影响。

其中灾备中心数据库平台要求与主中心架构一致，如均为SUN小型机。操作系统版本及数据库版本均需要一致。

Data Guard不支持异构平台数据容灾，也不支持不同数据库版本之间做数据容灾。

6、使用主中心备份的文件创建灾备中心数据库系统。

该操作主要是解压文件、恢复数据文件的时间。约为2小时。

7、配置灾备中心环境。根据主中心的归档日志保持灾备中心与主中心一致 。

3.5 用户需求点对点应答

3.5.1日常功能



将生产中心发卡系统上的数据库变化实时异步复制到灾备中心；

应答：满足。Data Guard通过归档日志将数据库变化复制到灾备中心。



灾备中心的Oracle数据库处于打开状态，可提供实时数据查询；

应答：部分满足。物理Data Guard在正常恢复的时候无法处于打开状态，在打开的状态下无法处于恢复与主数据库保持一致的状态。本系统的RPO<15分钟，RTO<6小时，每天归档日志产生量<20G。可以考虑以下方式解决该问题：

如果用户对容灾数据库使用时间为白天，那么在白天，将数据库启动为只读打开模式，供业务查询。夜间，将数据库启动为恢复模式，保持与主生产中心一致。如果用户对容灾数据库使用时间为夜间，那么反之在夜间将数据库打开只读，白天数据库做恢复。

容灾中心数据库只在指定时间内对数据库做恢复，因此该数据库与主数据库之间存在1天的数据差异。虽然没有实时做数据恢复，归档日志文件在产生后会同步写入容灾中心，因此系统可以满足RPO<15分钟的要求。当出现需要启动备用中心的情况，备用中心需要先通过归档日志文件恢复数据。目前每天归档日志量<20G，系统使用这些归档日志恢复数据的时间< 2小时，能够满足RTO<6

太极计算机股份有限公司

小时的业务需求。

如果用户对容灾中心数据库使用为全天24小时，目前版本Data Guard无法满足要求，在Oracle11G 以后的版本提供该功能。



对生产系统的资源占用不能太多，不能影响到生产系统的正常运行；

应答：满足。采用物理Data Guard的最大性能模式，生产中心主机仅需要在归档日志产生后将归档日志文件写入异地容灾中心，对生产系统资源占用极少，不影响生产系统的正常运行。在网络出现故障或容灾中心出现故障时，不会影响到生产系统的正常运行。



对网络带宽的占用较低。

应答：满足。Data Guard传输内容数据变化产生的归档日志文件。目前每天归档日志产生量为20G，那么传输量为20G/天。

3.5.2故障切换



当生产中心的系统无法正常运行，而又不能在短期内恢复时，可利用灾备中心提供业务接管。

应答：满足。灾备中心可以提供数据库服务器。



灾备中心必须在生产中心不可用6小时之内完成业务接管。

应答：满足。灾备中心可以在6小时内完成业务接管。



当生产中心服务器恢复正常后，数据复制系统需要将灾备中心的最新数据反向复制回生产中心，实现业务的恢复。

应答：部分满足。系统切换可以分为有计划的停机以及故障停机。

在有计划停机的情况下，灾备中心数据库在启用的时候，数据库内容保持与生产中心完全一致。在主中心操作完成后，可以通过简单命令，将灾备中心启用期间数据修改反向复制回生产中心，实现业务的恢复。

在故障停机的情况下，主中心可能有部分数据(<15分钟)尚未传递到备份中心，在灾备中心启用的时候，主、备之间数据已不一致。因此需要将所有数据重新传递回主中心才能实现业务的恢复。

太极计算机股份有限公司

3.5.3基本要求



复制软件应满足在单机或RAC环境下，对Oracle在线日志(Online redo

log)的捕捉及复制；

应答：满足。Data Guard通过对Online redo log产生的归档文件复制来完成容灾。



支持Oracle中所有的常用数据类型，如Oracle中的LONG

、LONG

RAW、BLOB、CLOB、NCLOB、TIMESTAMP等，可实现用户自定义表、字段进行复制；

应答：满足。物理Data Guard支持Oracle中所有的常用数据类型



支持对数据库中常用DDL操作的复制；

应答：满足。物理Data Guard支持Oracle中常用DDL的操作复制。



支持事务复制，要求对数据库中较大的事务不会出现过多延迟；

应答：满足。物理Data Guard支持事务复制。对较大事务不会出现过多延迟。



支持没有PK/UK字段的表的同步。

应答：满足。物理Data Guard支持没有PK/UK字段的表的同步。



数据复制过程可根据需要灵活地进行控制或修改复制的方向，以满足业务需求；

应答：满足。Data Guard可以灵活地控制主、备节点的swithover切换。



支持在数据复制过程中对数据正确性进行校验，如正在复制的数据在之前就已经不一致，应提供报警功能，以便及时发现错误，避免错误的扩大；

应答：满足。物理Data Guard复制的前提条件是主、备数据库保持一致，因此不会出现复制的数据在之前已经不一致的情况。



提供专用图形化集中管理软件。

应答：满足。Data Guard Broker与OEM可以提供很方便的图形化集中管理。

3.5.4性能要求



数据库初始化同步

要求数据库复制软件能够将发卡系统的数据库中已有数据初始化同步到灾

太极计算机股份有限公司

备中心数据库。在初始化同步过程中，业务不能停止，但可选择业务量较小时段进行。在解决方案书中要求详细描述初始化数据同步解决方案，以及整个首次同步操作所需要的时间（以100GB数据为标准），并且要求列出整个首次初始化过程中是否需要人为干预，从而可以有效地评估整个首次数据初始化的工作量。

为了保证生产中心日后业务扩展存在更换服务器厂商以及数据库版本等情况，需要注明是否支持异构平台下的首次数据初始化同步，是否支持跨数据库版本之间数据库的初始化同步操作。

应答：满足。详见Data Guard初始安装步骤

 数据复制性能指标

数据复制的性能指标与系统平台、网络带宽、应用系统等因素密切相关，参照下列运行环境：

项目

数据源

目标端

总数据量

每天的日志量

网络带宽

配 置

SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2 RAC

SF15K 24个CPU，32GB内存， ORACLE 10.2.0.2

500GB左右（数据+索引）

每天20GB日志

100M和20M

指标

首次数据库初始化同首次数据初始化同步

步时间（100M带宽）

首次数据库初始化同步时间（20M带宽）

首次数据库初始化同步源端CPU占用

增量数据同步

（单个复制链路）

源端CPU占用

目标端CPU占用

源端内存占用

目标端内存占用

参考值

小于10小时

小于48小时

小于30％

小于5％

小于5％

小于200M

小于200M

时

满足，首次初始化同步时间小于12小时

满足，对主系统资源消耗极小。小于1%

满足，对主系统资源消耗极小。小于1%

满足，对目标资源消耗极小。小于5%

满足，对主资源消耗极小。无需额外内存消耗

满足，对主资源消耗极小。无需额外内存消耗

不满足。在最大性能模式下，物理应答

满足，首次初始化同步时间小于5小

要求提供相应的性能参数指标：

类别

复制数据延迟平均值 10s以内

太极计算机股份有限公司

Data Guard在日志切换后将改变的数据写入灾备中心。频繁的日志切换将影响数据库运行性能。建议将日志切换频率设置为10分钟。因此数据复制最大延迟约为10分钟。

满足，对主系统资源消耗极小。小于1%

满足，对目标资源消耗极小。小于5%

不满足。在最大性能模式下，物理Data Guard在日志切换后将改变的数据写入灾备中心。频繁的日志切换将影响数据库运行性能。建议将日志切换频率设置为10分钟。因此数据复制最大延迟约为10分钟。

源端CPU占用

业务高峰期对系统的影响

目标端CPU占用

小于10％

小于10％

复制数据延迟平均值 10s以内

3.5.5数据一致性

要求数据库复制软件提供数据库初始化同步、数据恢复后以及日常的数据一致性检查方案，要求方案中详细注明该数据一致性比对方案的特点以及操作复杂度，并可满足如下要求：



可在应用不停机的情况下，查找和发现不一致的数据；



一致性检查需要能够进行对象属性、记录条数和记录的字段内容进行一致性检查；



提供全库的记录级一致性检查时间（以100GB的数据为例）。



支持不含PK/UK字段的表的一致性检查和修复。请提供在没有PK/UK字段的表中有1000万条记录的比对时间。

对于不一致的数据，需要提供不一致记录详细信息，以便进行精确的修复，同时提供数据修复方案。数据修复工作要求操作简单，修复速度快，且修复过程中不影响业务正常运行。

应答：满足。Data Guard实现的基本原理既：通过备份恢复的基本原理保持灾备数据库与主数据库的一致。只有主数据库可以修改，备数据库是不能够做任何改动的。当系统发生Switchover的切换以后，主备关系变化，同样只有主数据库（原来的备数据库）可以修改，备数据库（原来的主数据库）是不可以修改的。因此

太极计算机股份有限公司

Data Guard不存在查找和发现不一致的数据的问题。如果备数据库做了相应修改，那么数据复制的基础被打破，数据复制将无法继续进行，需要重新构建灾备中心数据库系统。

3.5.6系统兼容性

数据库复制软件应支持以下操作系统平台：

 Sun Solaris 9,10

 IBM AIX 5.x

数据库复制软件应支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持异构平台，源端和目标端不同数据库版本；支持Cluster/HACMP和RAC模式，并支持不同操作系统下不同数据库版本之间的复制。

应答：部分满足。

Data Guard支持Sun Solaris 9,10以及IBM AIX 5.x

Data Guard 支持Oracle 9i，Oracle 10g，Oracle 11g及后续数据库版本；支持Cluster/HACMP和RAC模式。

不支持异构平台，不支持源端和目标端不同数据库版本，不支持不同操作系统下不同数据库版本之间的复制。

3.5.7高可用性

主系统和备用系统的数据库处于双活状态，以保证在灾难发生前可在两个系统上运行不同类型的应用程序。

应答：部分满足。物理Data Guard在正常恢复的时候无法处于打开状态，在打开的状态下无法处于恢复与主数据库保持一致的状态。本系统的RPO<15分钟，RTO<6小时，每天归档日志产生量<20G。可以考虑以下方式解决该问题：

如果用户对容灾数据库使用时间为白天，那么在白天，将数据库启动为只读打开模式，供业务查询。夜间，将数据库启动为恢复模式，保持与主生产中心一致。如果用户对容灾数据库使用时间为夜间，那么反之在夜间将数据库打开只读，白天数据库做恢复。

容灾中心数据库只在指定时间内对数据库做恢复，因此该数据库与主数据

太极计算机股份有限公司

库之间存在1天的数据差异。虽然没有实时做数据恢复，归档日志文件在产生后会同步写入容灾中心，因此系统可以满足RPO<15分钟的要求。当出现需要启动备用中心的情况，备用中心需要先通过归档日志文件恢复数据。目前每天归档日志量<20G，系统使用这些归档日志恢复数据的时间< 2小时，能够满足RTO<6小时的业务需求。

如果用户对容灾中心数据库使用为全天24小时，目前版本Data Guard无法满足要求，在Oracle11G 以后的版本提供该功能。

数据库复制软件应支持本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可通过Cluster软件接管到其它节点。

应答：满足。数据库复制软件应本地Cluster/HACMP的高可用方式，在本地单节点出现故障时，可通过Cluster软件接管到其它节点。

3.5.8健壮性要求

数据库复制软件在各种大压力和各种故障情况下不会造成数据复制失败。



网络故障：长时间中断、短时间中断及网络时断时续情况下的正常复制；



数据库故障：在目标端数据库故障下，

源端数据库不能受到影响。当目标端数据库修复后，复制软件继续工作；



服务器硬件故障：在目标端服务器故障下，

源端生产系统不能受到影响，当目标端修复后，复制软件继续工作。

应答：满足。物理Data Guard 的最大性能模式下灾备中心服务器硬件、数据库故障以及网络故障均不会影响主中心的正常运行。如果主数据库与备用数据库之间的连接丢失（例如，由于网络问题、灾备数据库问题、灾备服务器问题），则在主数据库上生成的重做数据将无法发送到那些备用数据库上。一旦重新建立连接，Data Guard 就自动检测丢失的存档日志序列（或间隔），并将必要的存档日志自动传输到备用数据库中。备用数据库将重新与主数据库同步，而无需管理员的任何手动干预。

3.5.9设备无关性

独立于任何硬件设备、操作系统和Oracle数据库的不同版本，能够实现不

太极计算机股份有限公司

同平台之间数据库的复制。

应答：不满足。Data Guard 要求主备中心硬件架构相同，数据库版本完全一致。目前本系统中主备中心能够满足Data Guard的硬件及数据库版本要求。

3.5.10管理监控功能

数据库复制软件需提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时具有完整方便的报警及跟踪机制，方便故障的快速定位和解决。

应答：满足。Data Guard Broker与OEM可以提供统一的管理监控功能，能实现对复制软件的运行状态、运行日志、系统配置等方面进行统一的管理及监控，保证出现错误时具有完整方便的报警及跟踪机制，方便故障的快速定位和解决。

第四章Oracle Data Guard 10g R2概念和理论

分类： 理论知识2012-12-17 18:49 785人阅读 评论(0) 收藏 举报

网上很多文章都只是介绍如何搭建Oracle Data Guard，但是很少有介绍到基本的概念和理论知识。同时官方文档是纯英文的，对于英文不好的读起来是非常痛苦。本人因为是英文专业，结合官方文档和自己所学，整理了以下这些文字，和大家一起共同学习。同时感谢谢永生（Warehouse）和OCM群中的其他兄弟们，并以此文献给口香糖同学新出生的儿子。

1． Oracle Data Guard介绍：

Oracle Data Guard是Oracle数据库高可用技术中的一种，通过数据冗余为企业级数据库提供高可用，数据保护和灾难恢复。Data Guard 通过日志同步机制，在主备库之间实现数据同步，由于相互之间是通过网络连接，所以每个库可以放置在不同的地理位置，只要保证

太极计算机股份有限公司

网络连接通畅即可。如果主库发生计划中或者异常停机，Data Guard可以将任何1台Standby数据库切换成Primary数据库继续提供服务。

1.1. Primary数据库：

Data Guard配置中包含1台生产数据库，这台数据库可以是单实例也可以是RAC集群，负责对外提供大部分服务，在Data Guard中这台的角色就是Primary。

1.2. Standby数据库：

在一套Data Guard中最多可以有9台Standby数据库，Primary数据库通过网络将日志传输到Standby数据库，然后Standby在接收完日志后进行应用，以实现主备库之间的数据同步和事务一致性。和Primary数据库一样，Standby数据库也可以是单实例或者RAC集群。根据Redo Log的应用方式不同，Standby数据库又可以分为物理Standby和逻辑Standby。另外Data Guard是通过控制文件来识别Primary和Standby数据库的，所以Standby数据库的控制文件一定不能用操作系统复制，一定要通过命令ALTER DATABASE CREATE STANDBY

CONTROLFILE AS来进行创建。

1.2.1. 物理Standby：

物理Standby使用的是Media Recovery技术，通过Redo Apply，使用从主库接收到的Redo Log进行恢复，是基于block级的恢复，所以主备库中所有的schema都是完全一样的。物理Standby必须在mount阶段才能进行恢复，但是能通过只读方式打开，在10g版本中如果以只读方式打开的话就无法进行恢复操作。所以在某些情况下，Standby可以分担一部分查询和备份的压力，但是Data Guard还不能作为性能优化的解决方案。

1.2.2. 逻辑Standby：

逻辑Standby使用的是Log Miner技术，把Redo Log中的内容还原成SQL语句，通过SQL

Apply在备库执行SQL语句来实现数据同步。Log Miner不支持所有的数据类型，不支持

太极计算机股份有限公司

的类型可以在DBA_LOGSTDBY_UNSUPPORTED视图中进行查看。逻辑Standby可以在恢复的同时进行写操作。

1.3. Data Guard保护模式

1.3.1. 最大保护模式Maximum protection

在这种模式下，能够确保在Primary宕机时数据没有任何丢失。在事务提交之前，Primary数据库将Redo Log写入本地Online Redo Log，同时写入Standby数据库的Standby Redo

Log，并且确保至少Redo Log在一个Standby数据库上可用，这样事务才会被提交，否则Primary会被shutdown。

1.3.2. 最高可用模式Maximum availability

最高可用和最大保护类似，也是确保Redo在写入本地Online Redo Log和至少一个Standby数据库的Standby Redo Log，事务才会被提交。但是和最大保护不同的是，如果发生故障（如网络中断）导致Redo Log无法被写入Standby数据库时，Data Guard会自动切换到最高性能模式，而不是shutdown Primary数据库。当故障排除，Redo Log的gap被解决之后，Data Guard会自动切换回最高可用模式。

1.3.3. 最高性能模式Maximum performance

Data Guard默认模式。在这种模式下，Primary数据库在写入本地Online Redo Log之后就提交事务，写入Standby Redo Log是异步的，所以对于Primary性能影响是最小的。

1.3.4. 设置Data Guard保护模式

Redo归档进程

网络传输模式

Maximum

protection

最大保护

LGWR

SYNC

Maximum

availability

最高可用

LGWR

SYNC

Maximum performance

最高性能

LGWR或ARCH

如使用LGWR: SYNC或

太极计算机股份有限公司

磁盘I/O模式 AFFIRM

是否必需Standby 是

Redo Log

AFFIRM

是

ASYNC

如使用ARCH: SYNC

AFFIRM或NOAFFIRM

否，但是建议创建

改变Data Guard保护模式可以在Primary数据库（mount阶段）执行SQL语句：ALTER

DATABASE SET STANDBY DATABASE TO MAXIMIZE {PROTECTION |

AVAILABILITY｜ PERFORMANCE}，另外通过SQL语句：SELECT

PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE 可以查看当前数据库的保护模式。

1.4. 跨平台Data Guard 配置条件

除了相同的操作系统平台，Data Guard支持跨操作系统。

Oracle版本必须是10g及以上，同时Primary和Standby的操作系统必须有相同的字节序（同为big endian或者little endian），可以通过查询视图V$TRANSPORTABLE_PLATFORM获取信息。

2． Online Redo Logs,Archived Redo Logs, and Standby Redo Logs

2.1. Online Redo Logs

Primary数据库和逻辑Standby数据库都会用到Online Redo Log，但是物理Standby数据库是不使用Online Redo Log的，因为物理Standby只能以只读方式打开，不会有写操作，所以不会有Redo Log产生。

2.2. Archived Redo Logs

Primary数据库和Standby数据库（逻辑和物理）都需要用到Archived Redo Log，来保证Primary和Standby的事务一致性。

2.3. Standby Redo Logs

太极计算机股份有限公司

Standby Redo Log是Standby数据库用来存放从Primary数据库接收到的Redo Log的，以下几种情况必须要使用Standby Redo Log：

Ø 最大保护和最高可用模式 见1.3 Data Guard保护模式。

Ø Real-time apply

Ø Cascaded destinations

Standby Redo Log组的数量必须不少于Primary数据库的Online Redo Log组的数量，建议比Online Redo Log多1组。可以通过观察RFS进程的trace文件或者，如果日志中记录了RFS进程频繁等待归档进程的话，就需要增加Standby Redo Log组。

SQL语句ALTER DATABASE ADD STANDBY LOGFILE GROUP 1(‘/disk1/’,

‘/disk2/’) size 20M; 用于添加一组Standby Redo Log。

SQL语句ALTER DATABASE ADD STANDBY LOGFILE MEMBER

‘/disk3/’TO GROUP 1; 用于在第1组Standby Redo Log中再增加一个member。

SQL语句ALTER DATABASE DROP STANDBY LOGFILE GROUP1; 用于删除一组Standby Redo Log。

3． Redo传输服务Redo transport services

Redo传输服务是用来自动将Primary数据库产生的Redo Log传输到Standby数据库，并且能自动处理因为网络故障导致的归档日志gap。为了保障日志传输的安全性，Oracle是通过SYS密码来验证的，所以必须确保Primary数据库和所有的Standby数据库密码一致，并且参数REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE必须设置。

3.1. Redo传输路径的类型

Ø Data Guard Standby数据库 逻辑或者物理Standby数据库

太极计算机股份有限公司

Ø 归档日志容器 类似于Data Guard，archive log repository也是使用Standby controlfile和pfile来启动实例到mount阶段，但是这个数据库没有数据文件，无法进行切换，仅仅是用于保存归档日志。

Ø Stream实时下游捕获数据库 Oracle流复制技术，此处不做深入讨论。

Ø Oracle Change Data Capture stagingdatabase

3.2. 使用LOG_ARCHIVE_DEST_n参数来设置Redo传输路径

LOG_ARCHIVE_DEST_n参数一共有10个（n从1到10），每一个参数都必须使用LOCATION或者SERVICE属性来指定传输路径。对应的LOG_ARCHIVE_DEST_STATE_n参数用来控制其状态，

LOG_ARCHIVE_DEST_STATE_n共有4种状态：

Ø ENABLE 这是默认状态，Redo传输服务会发送日志到参数指定的路径。

Ø DEFER 表示路径有效，但是未使用。Redo传输服务不会把日志发送到指定的路径。

Ø ALTERNATE 表示路径不可用，但是如果和该路径设置为关联的另外一个路径失效的话，会切换成可用状态。

Ø RESET 功能和DEFER一样, 但是如果之前失效的话，会清除相关的错误信息。

3.3. LOG_ARCHIVE_DEST_n参数属性详解

3.1.1. LOCATION和SERVICE属性

每一个归档路径必须设置LOCATION或SERVICE属性，并且没有默认值。

Ø LOCATION

LOCATION=local_disk_directory或者也可以设置成LOCATION=USE_DB_RECOVERY_FILE_DEST，表示使用

太极计算机股份有限公司

DB_RECOVERY_FILE_DEST参数指定的路径。通常设置了DB_RECOVERY_FILE_DEST参数后，LOG_ARCHIVE_DEST_10会隐式的设置为USE_DB_RECOVERY_FILE_DEST，即归档到flash_recovery_area。

Ø SERVICE

SERVICE属性用于设置一个通过Oracle NET连接的远程归档路径，SERVICE=net_service_name。net_service_name必须在中事先定义好，并且通过tnsping命令确保连接畅通。视图V$ARCHIVE_DEST可以用来查看相关的设置信息。

3.1.2. ARCH和LGWR属性

该属性指定Redo传输服务使用ARCn进程或者LGWR进程来传输Redo Log。默认值是ARCH。

Ø ARCH

ARCH模式是通过ARCn进程，在数据库进行归档时将Redo Log写入指定路径。ARCH模式仅支持Data Guard中的最高性能模式。当Primary数据库触发了log switch事件，ARCn进程会开始本地归档，在归档成功之后，ARCn进程会将本地归档日志（非Online Redo Log）传输到Standby数据库。在Standby数据库上RFS进程（Remote File Server Process）会将日志依次写入归档日志，写完之后MRP进程（物理Standby）或者LSP进程（逻辑Standby）会将日志应用到Standby数据库。查看V$ARCHIVED_LOG视图可以检查归档日志是否成功写入。

Ø LGWR

LGWR模式在每一次commit之后，LGWR进程写本地Online Redo Log，同步或者异步（取决于SYNC和ASYNC）写入LOG_ARCHIVE_DEST_n参数指定的路径（Standby数据库必须存在Standby Redo Logs），如果该路径是远程的，LGWR进程会调用LNSn进程建立一个网络连接访问远端的实例并由该进程负责传输日志。在Standby数据库上RFS进程（Remote File Server Process）会将接收到的Redo Log写入Standby Redo Log中。Primary数据库发起的log switch会同步引起Standby数据库对Standby Redo Log进行归档，归档完成之后MRP进程（物理Standby）或者LSP进程（逻辑Standby）会在下一次

太极计算机股份有限公司

归档完成之后将日志应用到Standby数据库。如果启用了LGWR模式，在归档的时候除了本地归档就不会再触发ARCH进程写远程归档路径了，但是如果LGWR在写目标路径时失败，则会自动转换成ARCH模式，直到错误排除。

Ø 使用注意点

a. 如果不指定是ARCH或LGWR，则默认是ARCH。

b. ARCH模式使用的是ARCn进程，LGWR模式则是使用LGWR进程。同一个归档路径不能同时指定两种模式，但是一个数据库中的多个路径可以使用不同的模式，比如LOG_ARCHIVE_DEST_2是ARCH，LOG_ARCHIVE_DEST_3是LGWR。

c. 如果通过ALTER SYSTEM修改了一个归档路径的模式，比如从ARCH修改到LGWR，不是立刻生效的，必须等到下一次log switch才会生效。

3.1.3. SYNC和ASYNC属性

控制LGWR或ARCH进程在写Redo Log时是同步还是异步写。

3.1.4. AFFIRM和NOAFFIRM属性

该属性指定Redo传输服务在写Archived Redo Log和Standby Redo Log时，磁盘I/O是否同步。

Ø AFFIRM

表示Redo传输服务在写Archived Redo Log和Standby Redo Log时，Primary和Standby两边的磁盘I/O是同步的。并且只有在两边都成功写入后，Log写进程才会继续。

Ø NOAFFIRM

默认值，表示Redo传输服务在写Archived Redo Log和Standby Redo Log时是异步的，Primary端的日志写进程不会等待Standby端写Archived Redo Log和Standby Redo Log。

Ø 使用注意点

太极计算机股份有限公司

a. 当Data Guard为最大保护或最高可用模式，并且设置为LGWR和SYNC时，该参数自动设置为AFFIRM。

b. 如果指定了LGWR和AFFIRM，Primary和Standby两边日志写进程会同时写Redo，直到两边的磁盘I/O都完成了用户才能继续操作。

c. 如果指定了ARCH和AFFIRM，ARCn进程会同步将Redo写入本地归档目录和远程路径，所以归档操作会消耗更长的时间。

d. 如果指定了ASYNC和AFFIRM，那么Primary数据库性能将不受影响。

e. AFFIRM和NOAFFIRM对于Primary数据库的Online Redo Log没有影响。

重点：SYNC/ASYNC，AFFIRM/NOAFFIRM 这2对属性单独理解比较困难，需要结合起来一起分析。这2对属性控制了Data Guard在做同步数据时的方式，同时也决定了Data

Guard的保护模式。下面结合LGWR和ARCH来分别看这2对属性是如何控制数据同步的。

LGWR模式：

在Primary数据库产生commit事件之后，Primary数据库通过LGWR进程写Online Redo

Log，此时LGWR进程会同步或者异步（SYNC/ASYNC）写入Standby Redo Log。如果该归档路径是远程的（归档路径设置为SERVICE），那么LGWR进程会调用LNSn进程，通过Oracle Net建立网络连接，然后往Standby数据库传输Redo Log。在Standby数据库，RFS进程（Remote File Server Process）在接收到LNSn进程传输来的Redo Log后，如果是AFFIRM，那么RFS进程会在成功写入Standby Redo Log之后返回给Primary数据库一个处理结果，Primary数据库的LGWR进程会进行等待直到Standby数据库返回处理结果。如果是NOAFFIRM，那么Standby数据库的RFS进程在接收到Redo Log后，在写入Standby Redo Log之前就返回给Primary数据库处理结果，此时Primary数据库的LGWR进程不会等待Standby数据库的RFS进程写Redo Log，因为已经提前收到了处理结果。

ARCH模式：

在Primary数据库发起log switch事件之后，Primary数据库会通过ARCn进程，将Online

Redo Log进行归档，写入本地归档路径。并且会通过Oracle Net建立网络连接，同步或者异步（SYNC/ASYNC）向Standby数据库传输归档日志（Archived Redo Log）。Standby

太极计算机股份有限公司

数据库的RFS进程在接收到ARCn进程传输来的Archived Redo Log后，如果是AFFIRM，那么RFS进程会在写完归档日志之后返回给Primary处理结果，在RFS进程写入期间，Primary数据库的ARCn进程会进行等待。如果是NOAFFIRM，则RFS在写归档日志之前先返回处理结果，此时Primary的ARCn进程在收到返回结果后就不会再等待RFS写归档日志了。

3.1.5. ALTERNATE属性

该属性用来指定当一组路径失败时，启用替补归档路径。

Ø 使用方法

Example 1. 自动fail over到替补归档路径

LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY ALTERNATE=LOG_ARCHIVE_DEST_2'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='LOCATION=/disk2MANDATORY'

LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

Example 2. 使用不同的Oracle Net自动fail over到Standby数据库上

LOG_ARCHIVE_DEST_1='LOCATION=/disk1MANDATORY'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='SERVICE=stby1_path1

OPTIONALALTERNATE=LOG_ARCHIVE_DEST_3'

LOG_ARCHIVE_DEST_STATE_2=ENABLE

LOG_ARCHIVE_DEST_3='SERVICE=stby1_path2OPTIONAL'

太极计算机股份有限公司

LOG_ARCHIVE_DEST_STATE_3=ALTERNATE

Ø 使用注意点

a. ALTERNATE属性是可选的，如果没有指定，那么在原始路径fail之后是无法自动切换到其他的归档路径上的。

b. 每一个LOG_ARCHIVE_DEST_n只能设置一个替补路径。

c. 当前可用的归档路径数量要符合LOG_ARCHIVE_MIN_SUCCEED_DEST参数的值（如果设置的话）。

d. 无法将自己设置为替补路径。

e. 至少要有一个本地强制归档路径。

f. 当一个路径失效时，替补路径会在下一次归档时才生效。

g. 如果设置了REOPEN属性，并且MAX_FAILURE属性为0，那么ALTERNATE将无效。如果同时设置了REOPEN和MAX_FAILURE，那么只有当失效的归档路径达到MAX_FAILURE指定的数量，ALTERNATE才会生效。

3.1.6. LOG_ARCHIVE_MAX_PROCESSES参数

当LOG_ARCHIVE_DEST_n采用ARCH模式时该参数用于限制开启ARCH的进程数量，最大值是30，可以通过ALTER SYSTEM来动态修改。默认情况下会自动开启4个ARCH进程，并且自动进行负载均衡。

3.1.7. VALID_FOR属性

太极计算机股份有限公司

语法为：VALID_FOR=(redo_log_type, database_ role)

redo_log_type的有效值为：ONLINE_LOGFILE,STANDBY_LOGFILE和ALL_LOGFILES。该参数指明了归档路径log_archive_dest_n对哪种类型的日志有效。

database_role的有效值为：PRIMARY_ROLE,STANDBY_ROLE和ALL_ROLES。该参数指明了归档路径

log_archive_dest_n在哪个数据库角色下生效。

如果未设置VALID_FOR属性，默认相当于设置了VALID_FOR=(ALL_LOGFILES,

ALL_ROLES)。

3.1.8. DB_UNIQUE_NAME属性

此处的DB_UNIQUE_NAME是指设置在LOG_ARCHIVE_DEST_n参数里的，当LOG_ARCHIVE_DEST_n参数设置了SERVICE属性，则必须同时设置DB_UNIQUE_NAME。

例如：

LOG_ARCHIVE_DEST_2='SERVICE=boston LGWRASYNC

VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=boston'

这个属性的值和参数LOG_ARCHIVE_CONFIG以及参数DB_UNIQUE_NAME的值都对应，如果上述例子中，Standby数据库（boston）的DB_UNIQUE_NAME不是boston，则LOG_ARCHIVE_DEST_2在归档到Standby数据库时连接会被拒绝。

3.1.9. REOPEN和MAX_FAILURE属性

语法为：LOG_ARCHIVE_DEST_1='LOCATION=/arc_destREOPEN=60

MAX_FAILURE=3' ，REOPEN可以单独使用，但是MAX_FAILURE必须和REOPEN一起使用。

太极计算机股份有限公司

REOPEN属性用来设置该归档路径是否会自动重试，单位为秒，默认值300秒。比如上例中如果第一次Redo传输失败，那么在60秒后，ARCn或者LGWR进程会尝试重新传输日志。如果REOPEN=0表示关闭重试功能。

MAX_FAILURE属性用来设置连续失败的次数。比如上例中如果传输日志失败后每隔60秒会重试，重试失败3次后会关闭自动重试功能。

ORY和OPTIONAL属性

语法为：LOG_ARCHIVE_DEST_3= 'LOCATION=/arc_dest MANDATORY | OPTIONAL'

该属性的含义是假如设置了MANDATORY，那么在log switch之后，如果该归档路径下的归档操作没有成功，那么对应的那一组Online Redo Log也不会被覆盖和重用，只有在错误排除后那一组Online Redo Log才变为可用状态。如果设置为OPTIONAL，那么即使发生归档错误，Online Redo Log也会再次被标记为可用状态。

默认值是OPTIONAL，但是即使所有的归档路径都设置了OPTIONAL，仍然有一个本地归档路径是MANDATORY以此来保证至少有一组归档日志是可用的。

3.1.11. DEPENDENCY属性

该属性主要用于共享归档路径，必须和SERVICE一起使用，并且不能设置NOREGISTER属性。具体用法如下：

LOG_ARCHIVE_DEST_1='LOCATION=DISK1MANDATORY'

LOG_ARCHIVE_DEST_2='SERVICE=stdby1OPTIONAL'

LOG_ARCHIVE_DEST_3='SERVICE=stdby2OPTIONAL

DEPENDENCY=LOG_ARCHIVE_DEST_2'

以上示例是指Primary数据库将Redo Log传输到stdby1，但是不传输给stdby2，stdby2通过共享stdby1的Redo Log进行恢复。

太极计算机股份有限公司

3.1.12. DELAY属性

语法为：LOG_ARCHIVE_DEST_3='SERVICE=stbyC DELAY=120' 必须和SERVICE一起使用。

该属性主要作用是设置Standby数据库从接收到Redo Log到应用Redo Log恢复数据库之间的时间间隔，单位是分钟，默认是没有延迟。从Standby数据库接收到Redo Log并且完成归档动作之后开始计时，计时结束后才会应用Redo Apply去恢复数据库。通过以下语句可以关闭DELAY：

物理Standby： ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

NODELAY;

逻辑Standby： ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY;

3.1.13. MAX_CONNECTIONS属性

语法为：LOG_ARCHIVE_DEST_3='SERVICE=denverMAX_CONNECTIONS=3'

通常情况下Redo传输服务只会使用一个网络连接来执行远程归档，如果该属性的值设置大于1，Redo传输服务会使用多个网络连接。但是该属性同时受到LOG_ARCHIVE_MAX_PROCESSES和PARALLEL_MAX_SERVERS这两个参数影响。

3.1.14. NET_TIMEOUT

该属性必须在LGWR SYNC传输方式下使用，且仅对LNSn进程生效。单位是秒，默认是180秒。Primary数据库通过LNSn进程发送日志给Standby数据库，如果在NET_TIMEOUT参数指定时间内没得到Standby数据库的响应，则连接超时。如果是最大保护模式，那么数据库会在5分钟内重试连接，而不会立即shutdown Primary数据库。

3.1.15. NOREGISTER

太极计算机股份有限公司

如果SERVICE方式的归档路径不是Data Guard配置中的一部分，那么必须加上NOREGISTER。

3.1.16. TEMPLATE

设置归档日志文件的命名格式。仅对使用SERVICE的归档路径生效，不能命名LOCATION方式的归档日志。

3.1.17. VERIFY

指在完成归档操作后是否对归档日志进行验证。验证操作需要较长的时间来完成，并且可能对Primary数据库造成性能方面的影响。

3.4. 处理归档裂缝Archive Gap

Primary数据库完成了本地归档，但是在传输给Standby数据库时因为各种原因导致远程归档失败，那么这部分丢失的日志就是归档裂缝。

3.4.1. 自动处理归档裂缝

从Data Guard 10g版本开始，Primary数据库每隔1分钟会自动发起检查，如果发现裂缝会自动进行修复，不需要人工进行干预。FAL（Fetch Archive Log）机制有2部分组成，FAL server和FAL client。FAL client的作用是自动发起传输归档日志的请求，FAL server则响应请求并传输缺失的归档日志。如果Data Guard中有多个Standby数据库，FAL可以从其他的Standby数据库那获取归档日志。

FAL机制可以处理以下几种情况的日志裂缝：

太极计算机股份有限公司

a. 在创建Data Guard时，通过Primary数据库的热备份集创建Standby数据库后，FAL会自动检索Primary数据库的归档日志并恢复Standby数据库以进行同步。

b. 如果Standby数据库的归档日志在被应用之前就删除了，FAL会重新传输一份归档日志。

c. 因为磁盘错误等原因或者归档日志被其他文件覆盖导致归档日志无法被应用，FAL会重新传输一份归档日志。

配置该功能需要2个参数FAL_SERVER和FAL_CLINET，这2个参数的值都是在中预先定义的Oracle网络服务名：

FAL_SERVER：指定FAL机制获取归档日志的来源，可以包含多个值，例如FAL_SERVER=

primary_db,standby3_db。

FAL_CLIENT：指定FAL机制发起请求的客户端，一般来说是Standby数据库，例如FAL_CLIENT=standby1_db。

3.4.2. 手动处理归档裂缝

以下示例是物理Standby数据库手动处理的过程：

Step 1. 查询V$ARCHIVE_GAP视图获得归档裂缝。

Standby数据库：

SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#

----------- -----------------------------------------------

1 7 10

从视图中看出7号到10号归档日志丢失。

太极计算机股份有限公司

Step 2. 查询V$ARCHIVED_LOG获取归档裂缝所在的归档日志文件。

Primary数据库：

SQL> SELECT NAME FROM V$ARCHIVED_LOG WHERE THREAD#=1 AND

DEST_ID=1 AND SEQUENCE#BETWEEN 7 AND 10;

NAME

--------------------------------------------------------------------------------

/primary/thread1_dest/arcr_1_

/primary/thread1_dest/arcr_1_

/primary/thread1_dest/arcr_1_

Step 3. 将以上3个文件copy到Standby数据库的/standby路径下，并注册到Standby数据库中。

Standby数据库：

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_’;

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_’;

SQL> ALTER DATABASE REGISTER LOGFILE ‘/standby/arcr_1_’;

Step 4. 重启Log Apply服务。

如果是逻辑Standby数据库，则通过在逻辑Standby数据库上查询

DBA_LOGSTDBY_LOG视图：

SQL> SELECT THREAD#, SEQUENCE#,FILE_NAME FROM DBA_LOGSTDBY_LOG L

太极计算机股份有限公司

2> WHERE NEXT_CHANGE# NOT IN

3> (SELECT FIRST_CHANGE# FROMDBA_LOGSTDBY_LOG WHERE # =

THREAD#)

4> ORDER BY THREAD#,SEQUENCE#;

THREAD# SEQUENCE# FILE_NAME

---------- ---------------------------------------------------------

1 6 /disk1/oracle/dbs/log-1292880008_

1 10 /disk1/oracle/dbs/log-1292880008_

将文件编号中7-9的文件从Primary数据库服务器copy到逻辑Standby数据库服务器上，并使用ALTER DATABASE REGISTER命令进行注册，注册后重启Log Apply服务。

4． 日志应用服务Log Apply Services

Standby数据库的RFS进程在接收到传来的日志之后，会写入本地的Standby Redo Log或者Archived Log中，取决于LGWR和ARCH（详见3.3.4）。在Standby Redo Log归档完成之后或者Archived Log写完之后，MRP进程（物理Standby）或者LSP进程（逻辑Standby）会将日志应用到Standby数据库。根据日志应用类型的不同，Standby分为物理Standby（Redo Apply）和逻辑Standby（SQL Apply）（详见1.2）。

4.1. Redo Apply （物理Standby）

默认情况下，在Standby Redo Log归档之后，MRP进程才会开始恢复数据库。但是在LGWR

SYNC模式下可以开启实时应用，或者设置DELAY属性开启延时应用。

Ø 开启Redo Apply：

太极计算机股份有限公司

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE; 开启前台Redo Apply，开启之后该命令行窗口会停留在Redo Apply阶段并且无法响应其他操作，直到其他的session终止了日志应用。

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE

{DISCONNECT | DISCONNECT FROM SESSION}; 开启后台Redo Apply，开启之后Redo Apply将在后台进行，命令行窗口可以继续操作。

Ø 开启Redo Apply实时应用：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE USING

CURRENT LOGFILE;

Ø 设置Redo Apply延时应用：

设置LOG_ARCHIVE_DEST_n参数中的delay属性（详见3.3.11）

Ø 取消Redo Apply延时功能：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE NODELAY;

Ø 关闭Redo Apply：

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE CANCEL;

SQL> ALTER DATABASE RECOVER MANAGEDSTANDBY DATABASE FINISH;

注意：cancel表示switchover, finish表示failover。

太极计算机股份有限公司

4.2. SQL Apply （逻辑Standby）

逻辑Standby是通过LSP进程，在Redo Standby Log归档之后，通过log miner技术从Redo中还原出SQL语句并应用到Standby数据库。

Ø 开启SQL Apply：

SQL> ALTER DATABASE START LOGICALSTANDBY APPLY;

Ø 开启SQL Apply实时应用：

SQL> ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

Ø 开启SQL Apply延时应用：

方法同Redo Apply。

Ø 取消SQL Apply延时功能：

SQL> ALTER DATABASE START LOGICALSTANDBY APPLY NODELAY;

Ø 关闭SQL Apply：

SQL> ALTER DATABASE STOP LOGICALSTANDBY APPLY;

5． 角色切换

Data Guard角色切换有两种方式：switchover 和 failover。

5.1. Switchover

太极计算机股份有限公司

5.1.1. 物理Standby

Switchover切换不会丢失数据，切换之后原先的Primary数据库和Standby数据库角色互换，并且每个数据库在Data Guard配置中仍然继续运行。切换必须从Primary数据库发起，具体步骤如下：

Step 1. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY则表示可以正常切换，如果是SESSIONS ACTIVE，在切换时带上WITH SESSION

SHUTDOWN 子句也可以成功切换。

Step 2. Primary数据库发起switchover切换，ALTER DATABASE COMMIT TO

SWITCHOVER TO PHYSICAL STANDBY; 切换之后重启实例 SHUTDOWN

IMMEDIATE; STARTUPMOUNT;

Step 3. Standby数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECTSWITCHOVER_STATUS FROM V$DATABASE），如果是TO PRIMARY则表示可以正常切换，如果是SESSIONS ACTIVE，在切换时带上WITH SESSION

SHUTDOWN 子句也可以成功切换。

Step 4. Standby数据库切换Primary数据库，ALTER DATABASE COMMIT TO

SWITCHOVER TO PRIMARY; 如果该Standby数据库从上次启动实例之后从未以read-only模式打开过，则直接ALTER DATABASE OPEN; 否则需要重启实例

SHUTDOWNIMMEDIATE; STARTUP;

Step 5. 如果必要的话，重启新Standby数据库的Log Apply服务 ALTER DATABASE

RECOVER MANAGED STANDBYDATABASE; （详见4.1）。

太极计算机股份有限公司

5.1.2. 逻辑Standby

同物理Standby一样，switchover也必须从Primary数据库发起。

Step 1. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列（SELECT SWITCHOVER_STATUS FROM V$DATABASE），如果是TO STANDBY或SESSIONS ACTIVE则表示可以正常切换。

Step 2. Primary数据库执行SQL语句ALTER DATABASE PREPARE TO SWITCHOVER

TOLOGICAL STANDBY;这一句SQL的作用是通知当前的Primary数据库准备切换至Standby，并从新的Primary数据库接收Redo Log。 此时V$DATABASE视图中SWITCHOVER_STATUS列的状态是PREPARING SWITCHOVER。

Step 3. Standby数据库执行SQL语句ALTER DATABASE PREPARE TO SWITCHOVER

TOPRIMARY; 这一句SQL的作用是在Standby数据库上启动Redo传输服务，此时该Standby数据库会将Redo Log传输到当前的Primary数据库和其他的Standby数据库，但是不做应用。

Step 4. Primary数据库检查视图V$DATABASE中的SWITCHOVER_STATUS列，在Step3完成后（LogMiner Multiversioned Data Dictionary被当前Primary数据库接收完成），SWITCHOVER_STATUS状态将变更为TO LOGICAL STANDBY。此时可以取消switchover切换，Primary和Standby分别执行SQL语句：ALTER DATABASE PREPARE

TO SWITCHOVERCANCEL;

Step 5. Primary数据库执行ALTER DATABASE COMMIT TO SWITCHOVER TO

LOGICAL STANDBY; 切换到Standby数据库。检查视图V$DATABASE中的SWITCHOVER_STATUS列，如果是TO_PRIMARY表示切换成功。