Oracle 11gR2 DataGuard 教程

（Physical Standby Database）

目录

第1章    理论基础    4

1.1    概述    4

1.2    日志发送    4

1.2.1    使用ARCH进程    4

1.2.2    使用LGWR进程的SYNC（同步）方式    4

1.2.3    使用LGWR进程的ASYNC（异步）方式    5

1.3    日志接收    6

1.4    日志应用    6

1.5    数据保护模式    7

1.5.1    最大保护（Maximum Protection）    7

1.5.2    最高可用性（Maximum Availability）    7

1.5.3    最高性能（Maximum Performance）    8

1.5.4    修改数据保护模式    8

第2章    配置    8

2.1    配置参数说明    8

2.1.1    参数    8

2.1.2    主库参数    10

2.1.3    备库参数    15

2.2    环境介绍    17

2.2.1    主库环境    17

2.2.2    备库环境    17

2.3    配置过程    18

2.3.1    主库配置    18

2.3.2    备库配置    21

2.3.3    复制数据库    23

2.4    其他问题    24

第3章    角色切换    25

3.1    SwitchOver    25

3.1.1    准备工作    25

3.1.2    主库切换为新备库    25

3.1.3    备库切换为新主库    25

3.1.4    新备库应用日志    26

3.2    FailOver    26

第1章 理论基础

1.1概述

DataGuard至少需要两个数据库，一个以READ WRITE（读写）模式打开，进行在线事务处理，角色称为Primary Database（主库），一个以READ ONLY（只读）模式打开，接收重做日志并重新应用，角色称为Standby Database（备库）。

用户连接主库进行事务处理，更改操作被记录在联机重做日志和归档重做日志中，这些日志通过网络发送给备库并在备库上重新应用，最终实现主备库数据同步。

DataGuard由重做传输服务，应用服务和角色管理服务组成，其中前两项服务按照功能分为Redo Send（日志发送），Redo Receive（日志接收）和Redo Apply（日志应用）三个部分。DataGuard分为Physical Standy（物理备库）和Logical Standby（逻辑备库）两种，本教程只讨论Physical Standby。

1.2日志发送

主库在运行时会不断产生重做日志，这些日志需要发送到备库。发送动作可以由主库的LGWR进程或者ARCH进程完成，默认使用ARCH进程，如果使用LGWR进程必须明确指定。不同的归档目的地可以使用不同的方法，但对于同一目的地，只能选用1种方法。

1.2.1使用ARCH进程

主库不断产生重做日志，这些日志被LGWR进程写入主库联机重做日志文件，此时事务提交即可返回成功；

当一组联机重做日志文件被写满后，会发生日志切换（Log Switch）并触发ARCH进程进行本地归档；

主库的ARCH进程通过网络把这些归档日志发送给备库。

使用ARCH进程发送日志的问题：

主库只有在发生归档时才会发送日志到备库，如果主库异常宕机，联机日志中的重做数据就会丢失，要想避免数据丢失，就必须使用LGWR进程发送日志，而使用LGWR 进程又分SYNC（同步）和ASYNC（异步）两种方式。

1.2.2使用LGWR进程的SYNC（同步）方式

主库不断产生重做日志，这些日志被LGWR进程写入主库联机重做日志文件，同时发送给本地的LNS进程（Logwriter Network Service）；

LNS进程通过网络把重做日志发送给远程目的地（每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作）并等待远程确认传送成功；

LGWR进程等待本地联机重做日志文件的写入操作和通过LNS进程的网络传送都成功，确认主库事务提交成功。

当一组联机重做日志文件被写满后，会发生日志切换（Log Switch）并触发ARCH进程进行本地归档，同时触发备库的日志切换和备库重做日志的归档。

使用LGWR进程的SYNC（同步）方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，如果网络发送在此时间内没有响应，LGWR进程就会返回错误。示例如下：

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30' SCOPE=BOTH;

使用LGWR进程的SYNC（同步）方式问题在于：

如果发送重做日志给备库失败，LGWR进程就会报错，分三种情况：

主库工作在最大保护模式下，事务提交会返回失败，无重做数据生成，同时主库被SHUTDOWN，待问题解决后主库才能成功启动；

主库工作在最大可用模式下，事务提交会返回成功，重做数据只写入本地日志文件，同时主库由最大可用模式降为最大性能模式，待问题解决后备库自动向主库请求传送缺失的日志并应用，主库重新恢复为最大可用模式；

主库工作在最大性能模式下，事务提交会返回成功，重做数据只写入本地日志文件，待问题解决后备库自动向主库请求传送缺失的日志并应用。

采用SYNC（同步）方式，主库的LGWR进程高度依赖网络状况，在某些情况下，这种要求可能过于苛刻，这时就可以使用LGWR进程的ASYNC（异步）方式。

1.2.3使用LGWR进程的ASYNC（异步）方式

主库不断产生重做日志，这些日志被LGWR进程写入主库联机重做日志文件，同时发送给本地的LNS进程（Network Server Process），一旦成功写入联机重做日志文件，事务提交即可返回成功；

LNS进程异步通过网络把重做日志发送给远程目的地（每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作）；

当一组联机重做日志文件被写满后，会发生日志切换（Log Switch）并触发ARCH进程进行本地归档，同时触发备库的日志切换和备库重做日志的归档。因为LGWR进程不会等待LNS进程的响应结果，所以配置LGWR进程ASYNC（异步）方式时不需要NET_TIMEOUT参数。

1.3日志接收

备库的RFS（Remote File Server）进程接收到重做日志，将其写入Standby Redo Log（SRL，备库重做日志）文件或者归档重做日志文件，具体写入哪个文件，取决于主库的日志传送方式（ARCH或LGWR）和备库的位置（本机或远程）。如果写入SRL文件，则当主库发生日志切换时，也会触发备库SRL切换，并把这个SRL归档。如果是写入归档日志文件，那么这个动作本身也可以看作是个归档操作。

在日志接收中，需要注意的是备库归档日志的存放位置，具体如下：

如果配置了STANDBY_ARCHIVE_DEST参数，则使用该参数指定的目录；

如果某个LOG_ARCHIVE_DEST_n参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)选项，则使用这个参数指定的目录。

如果数据库的COMPATIBLE参数大于等于10.0，则选取任意一个LOG_ARCHIVE_DEST_n的值。

如果STANDBY_ARCHIVE_DEST和LOG_ARCHIVE_DEST_n参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值可以通过以下命令查询：

SQL>SHOW PARAMETER STANDBY_ARCHIVE_DEST

1.4日志应用

日志应用，就是在备库上应用重做日志，实现主备库数据同步。

物理Standby使用MRP进程（Managed Recovery Process）,利用Media Recovery（介质恢复）技术应用重做日志，在数据块级别进行恢复，这种方式叫做Redo Apply，没有数据类型的，可以保证两个数据库完全一致。

物理Standby只能在MOUNT（加载）状态下进行恢复，也可以是OPEN（打开）状态，但只能以READ ONLY（只读）模式打开，且打开时不能执行恢复操作。（注意：Oracle 11g已经支持以只读模式打开的同时进行恢复操作，即READ ONLY WITH APPLY）。

逻辑Standby使用LSP 进程（Logical Standby Process），利用Logminer技术把日志内容还原成SQL语句，SQL引擎执行这些语句，这种方式叫SQL Apply，不支持所有数据类型（可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看不支持的数据类型），如果使用了不支持的数据类型，则不能保证数据库完全一致。

逻辑Standby可以在恢复的同时进行读写操作。

根据Redo Apply发生的时间可以分成两种：

Real-Time Apply（实时应用），这种方式必须使用LGWR进程传送重做日志，每当日志被写入备库重做日志时，就会触发应用，使用这种方式可以减少数据库切换（Switchover 或者Failover）的时间，因为切换时间主要用在剩余日志的应用上。

归档时应用，这种方式在主库发生日志切换，触发备库归档操作，归档完成后进行应用，这是默认的应用方式。

物理Standby启用实时应用的命令：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

逻辑Standby启用实时应用的命令：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

查看是否启用实时应用的命令：

SQL>SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS;

1.5数据保护模式

Data Guard 允许定义三种数据保护模式，分别是最大保护（Maximum Protection），最大可用（Maximum Availability）和最大性能（Maximum Performance）。

最大保护（Maximum Protection）

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的在线重做日志文件，还要同时写入到备库的重做日志文件，并确认REDO数据至少在一个备库中可用（如果有多个的话），然后才会在主库上提交。如果出现故障导致备库不可用的话（例如网络中断），主库会被SHUTDOWN，以防数据丢失。

使用这种模式要求备库必须配置重做日志文件组，而主库必须使用LGWR进程的SYNC,AFFIRM 方式传送日志到备库。

最高可用性（Maximum Availability）

这种模式在不影响主库可用前提下，提供最高级别的数据保护策略。其实现方式与最大保护模式类似，同样要求本地事务在提交前必须至少写入一个备库的重做日志文件中。

与最大保护模式不同的是，如果备库由于故障无法访问，主库不会被SHUTDOWN，而是自动转为最高性能模式，等备库恢复正常之后，主库又会自动转换成最高可用性模式。

这种模式会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求备库必须配置重做日志组，而主库必须使用LGWR进程的SYNC，AFFIRM 方式传送日志到备库。

最高性能（Maximum Performance）

这种模式在不影响主库性能前提下，提供最高级别的数据保护策略。事务可以随时提交，当前主库的REDO数据至少需要写入一个备库的重做日志文件，不过这种写入可以是不同步的。如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对主库的性能有轻微影响。这也是创建备库时系统的默认保护模式。

这种模式可以使用LGWR进程的ASYNC方式或者使用ARCH进程传送重做日志，备库也不要求使用重做日志。

修改数据保护模式

关闭数据库，重启到MOUNT状态，如果是RAC，需要关闭所有实例，然后只启动一个实例到MOUNT状态。

修改模式

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

打开数据库

SQL> ALTER DATABASE OPEN;

确认修改数据保护模式

SQL>SELECT PROTECTION_MODE, PROTECTION_LEVEL FROM V$DATABASE;

第2章 配置

2.1配置参数说明

参数

参数与角色无关，主备库中都需要进行配置。

⏹DB_UNIQUE_NAME

该参数定义了数据库的唯一名称。因为DB_NAME参数需要满足与物理备用数据库名称保持一致，和逻辑备用数据库名称不相同的条件，所以在10g中该参数被引入，用来区分DataGuard配置中的每一个数据库角色。这个参数需要在所有的数据库中配置，同时需要重启数据库才能生效。如果不配置这个参数，那么默认会使用DB_NAME参数，这就意味着我们不需要关闭生产库来完成备用数据库的配置工作，我们可以在之后进行配置。

SQL>ALTER SYSTEM SET DB_UNIQUE_NAME='crm_primaty' SCOPE=SPFILE;

⏹LOG_ARCHIVE_CONFIG

该参数定义了DataGuard配置中可用的DB_UNIQUE_NAME参数值列表。与目标参数DB_UNIQUE_NAME的值结合使用时，DataGuard以它们来实现两个数据库之间连接的安全性检查工作。只要不指定SEND和RECEIVE属性，这个参数就是动态的，这两个属性是旧参数REMOTE_ARCHIVE_ENABLE遗留下来的，已经不再需要，因此就不要再使用了。

在实际使用时，你只需要将其他数据库的唯一名称添加到配置就可以了，当前数据库的唯一名会根据场景自动添加；不过为了清晰期间，并且在所有的数据库中保持该参数的一致性，还是会将当前数据库的唯一名称明确的添加上去。对于名称的配置顺序没有要求，该参数在有RAC的环境中是必须要配置的，应该始终使用该参数。

SQL>ALTER SYSTEM SET LOG_ARCHIVE_CONFIG=‘dg_config(crm_primaty,crm_standby)’ SCOPE=BOTH;

⏹CONTROL_FILES

该参数指定当前数据库控制文件的位置。要记住对于备用数据库，它指向的是备用控制文件(Standby Control File)的位置。这个控制文件可自动创建或者手动创建，取决于你创建备用数据库的方法，自动创建通常发生在使用RMAN功能产生备用数据库过程中，如果使用手工创建，控制文件需要手动从主库复制过来。

⏹LOG_ARCHIVE_MAX_PROCESSES

该参数指定归档进程最大进程数。提到这个参数是因为它的默认值仍然是2（11g默认值为4），太小了。在主库中，归档进程负责归档已经写满的在线日志文件（ORL,Online Redo Log）并作为重做流(Redo Steam)传输到备用数据库来完成间隔处理(GAP)；在备库中，归档进程则是负责归档备库日志文件(Standby Redo Log)并且将其转发到它的级联备用数据库中 (级联备用数据库是指当前备用数据库的下一级备库，即备库的备库，从这里可以看出不管什么数据库角色，归档进程的工作的内容都是一样的：1.归档日志文件；2.转发日志文件到备库)。

在主库中，有一个归档进程仅限于对在线日志文件提供服务，无权与备库进行通信，这个特殊的ARCH进程被称为“专用ARCH进程”，而其他归档进程是可以完成这两样功能的。当归档进程向备库发送归档日志文件，就无法协助归档ORL文件了；尽管归档进程的主要指令是“先归档在线日志文件，再处理主备库的间隔”，但是在最坏的情况下，仍然可能只有一个归档进程在进行归档任务。如果没有足够的归档进程，在慢速网络，主备库间出现大的日志间隔的时候，可能就只有那么一个进程在处理日志文件。这里就会有个非常棘手的问题，那就是如果这个时候你所有的日志文件都已经写满，生产库就停滞了，直到其中的一个文件被归档。在10g中引入了多线程间隔处理特性(MAX_CONNECTIONS)，它允许DataGuard使用多个归档进程向备用数据库发送单个日志文件，这就意味这我们会使用更多的归档日志进程；因此，这个参数至少要设置4，最大值为30。

需要注意的是，备用数据库中也有一个“备库专用ARCH进程”，不过这仅仅意味着在备库中少了一个可以归档SRL文件归档进程而已，在物理备库中，这个专用ARCH进程是没有归档SRL文件功能的。下面的命令将归档最大进程数设置为10个：

SQL>ALTER SYSTEM SET LOG_ARCHIVE_MAX_PROCESSES=10 SCOPE=BOTH;

⏹DB_CREATE_FILE_DEST

仅在备库使用ASM时需要定义。

SQL>ALTER SYSTEM SET DB_CREATE_FILE_DEST=‘+DATA’;

主库参数

⏹LOG_ARCHIVE_DEST_n

这是DataGuard重做日志传输的主要参数，通常都是在主库中起作用，当然也会有例外，比如处理级联备库的场景。该参数也可用来指定由在线重做日志(ORL)或备库重做日志(SRL)产生的归档日志文件的传输目的地，不过随着10gR1版本中闪回恢复区的引入，本地归档的日志文件默认会放在闪回恢复区，所以在这种情况下就不需要再设置本地归档了。

这个参数有17个属性，所有这些属性都是用来设置主库到备库的重做日志传输的，其中有7个为必选属性，10个为可选属性（其中有6个属性建议不要进行设置），下面结合例子分别进行介绍。

1.必选属性

SERVICE

指定已经创建的备库的TNSNAMES描述符，早期的网络调整就是从这里开始的。(这是DataGuard设置中会较早碰到的与网络相关的属性)

SYNC

指定使用同步方式传送重做数据，即客户端事务的提交会发生在LGWR进程收到备库LNS发来的确认信息之后。对于”最大可用模式“和”最大保护模式“，这需要至少一个备库。

ASYNC

默认值；如果没有指定日志传输类型的话就会使用异步方式传送重做数据；这是“最大性能模式”下的日志传输方式。

NET_TIMEOUT

指定LGWR进程等待LNS进程响应的时间，如果这期间没有收到响应，则认为备库发生故障(failed)，默认值是30秒，不过10-15可能会是更恰当的值，这取决于你的网络可靠性。不要将这个值设置为10以下，不然你可能会在备库恢复正常后还是无法建立连接，这是因为重新连接备库的操作也会耗费几秒的时间。因此在这之前，我们需要做：

停止旧的LNS进程

启动新的LNS进程

与备库建立连接

检测并停止旧的RFS进程

启动新的RFS进程

选择并打开新的SRL

初始化SR头(即备库的重做日志数据)

响应LNS进程告知已经完成准备工作

所有这些操作完成后，LNS进程才会告诉LGWR进程备库已连接成功，如果这个过程耗费的时间超过了NET_TIMEOUT的值，那么LGWR会再次放弃备库；每次发生日志切换时都会进行这个重新连接动作。

REOPEN

该属性控制主库尝试重新连接已经发生故障的备库的等待时间（秒），默认值是300(5分钟)，这通常是大家抱怨在停止备库后主库不重连的原因。一般来说，测试的时候都会比较快；先SHUTDOWNABORT备库，观察主库的alert日志看是否与备库断开连接，再启动备库，在主库中切换日志观察是否发生重连，这些操作会在5分钟内完成，所以如果你动作快，DataGuard不会在第一次(或者更多次)日志切换时进行重连。这个属性旨在避免这种情况，即如果备库发生故障以后主库立即切换日志，这个时候的重连很有可能就会失败，因此你可以考虑将这个属性设置成30甚至是15，这样DataGuard会尽快的完成重连工作。

DB_UNIQUE_NAME

要在参数LOG_ARCHIVE_DEST_n参数中使用这个属性需要同时设置LOG_ARCHIVE_CONFIG参数，否则DataGuard将拒绝连接这个目标库；这个SERVICE目标(远端)名称是你用来连接另一端的数据库(也就是备用数据库)的唯一名称。

你必须同时在两端的数据库中将该唯一名称添加LOG_ARCHIVE_CONFIG参数中。当主库向备库发起连接时，它将会发送自己的数据库唯一名称到备库，同时要求备库返回唯一名称。在备库中将会检查LOG_ARCHIVE_CONFIG参数，以确保主库的唯一名确实存在，如果不存在，连接请求将会被拒绝；如果存在，备库会把自己的唯一名返送回主库的LNS进程，如果返送的值和主库中该属性的值不匹配，连接就会被终止。

和LOG_ARCHIVE_CONFIG参数一样，这个属性在RAC环境下是必须要配置的。

VALID_FOR

这是最后一个必须配置的属性了。尽管你认为不配置这个属性DG也能正常的工作(确实是这样)，不过还是建议你使用它。该参数的主要功能是定义何时使用目标参数LOG_ARCHIVE_DEST_n以及它作用于哪种类型的日志文件。

下面是日志文件的合法值：

✧ONLINE_LOGFILE             仅在归档ORL文件时有效

✧STANDBY_LOGFILE         仅在归档SRL文件时有效

✧ALL_LOGFILES             无论是那种重做日志文件类型都有效

下面是角色的合法值：

✧PRIMARY_ROLE            仅在主库中生效

✧STANDBY_ROLE            仅在备库中生效

✧ALL_ROLES                 主备角色都有效

如果这两个参数的答复都是TRUE，VALID_FOR就会允许使用目标参数。

注意：这里意思是目标参数会在VALID_FOR的上述两个子项都是TRUE的时候被使用。比如设置为valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)那么如果当前数据库满足是主库并且归档ORL文件的条件，LOG_ARCHIVE_DEST_n内的属性设置就会生效。

有了这个参数，我们就可以预定义DataGuard中所有数据库的所有目标参数了，并使其仅在VALID_FOR属性都是TRUE的时候生效，这样就没必要再在角色转换时启用和禁用目标了。

那么LOG_ARCHIVE_DEST_n到底会是什么样子呢？最多可以设置9个目标，这就是说我们可以最多拥有9个备库，其实可以使用10个，不过一个是保留用做默认的本地归档目标的，这个我们稍后会讨论。这里我们使用2号参数来添加一个备库：

SQL>ALTER SYSTEM SET LOG_ARCHIVE_DEST_2='service=service_crm_st async valid_for=(online_logfile,primary_role) db_unique_name=crm_standby’ SCOPE=BOTH;

2.可选属性

AFFIRM

这是使用SYNC方式目标的默认值。要求LNS进程等待RFS进程完成对SRL文件的直接I/O再返回成功消息，还要求是“最高可用”或”最大保护“模式。

因为这个属性是基于目标的默认值，所以不需要设置它，尽管在10g中可以为ASYNC方式的目标指定这个属性，不过依然是没有必要的。实际上，它会拖慢LNS进程（在11g中，AFFIRM属性会被ASYNC目标忽略掉）。

NOAFFIRM

如果没有特别指定，它会是ASYNC目标的默认值。用于“最大性能”模式；再次声明，因为它是ASYNC的默认值，所以没有必要去指定它；并且如果你对SYNC目标设置NOAFFIRM属性，你的保护模式将违反规定，被标记为“已重新同步”状态。如果这是你唯一的SYNC备库，并且处于最大可用模式，那么你将无法进行零数据丢失的故障转移(Failover)；如果这是你唯一的SYNC目标，并且处于最大保护模式，那么设置AFFIRM属性会让你的主库崩溃。

COMPRESSION

这个属性将启用对备用目标的高级压缩功能。默认情况下，这就意味着任何一个向该目标发送间隔日志的归档进程都会在发送时压缩归档。如果你设置了这个隐藏属性，那么它也会压缩当前发送的重做日志流。举个例子，假如设置这个隐藏参数，我们来对当前的两个目标库来添加COMPRESSION属性：

SQL> ALTER SYSTEM SET log_archive_dest_2='service=orcl

                    LGWR SYNC REOPEN=15 NET_TIMEOUT=15

COMPRESSION=ENABLE

                    valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)

                    db_unique_name=orcl' SCOPE=BOTH;

SQL> ALTER SYSTEM SET log_archive_dest_3='service=orcl_2

                    LGWR ASYNC REOPEN=15

COMPRESSION=ENABLE

                    valid_for=(ONLINE_LOGFILES,PRIMARY_ROLE)

                    db_unique_name=orcl_2' SCOPE=BOTH;

orcl目标库仅在ARCH进程发送用于间隔处理的归档日志的时候才会使用压缩功能(并非用于同步SYNC的归档日志)，而orcl_2库自始至终都会压缩重做日志。这里说明日志并不会在磁盘也保持压缩状态，因为只会在传输过程中压缩日志，所以这些传输到备库的数据会被解压缩，然后再写入到SRL文件中。

MAX_CONNECTIONS

该属性在10gR2中被引入，它允许你指定用于备库间隔处理的归档进程的数量，在11g中已经弃用（不要在11g数据库中使用MAX_CONNECTIONS属性，这会降低日志传输的性能）。

如果你的版本是10g，你可以为它指定值1-5(默认值1)，如果设置的值大于1时，每当备库需要进行间隔处理的时候，主库将分配对应数量的归档进程用来发送归档日志文件，这些文件会被分片给这些归档进程，同时在网络中以并行流的形式传送，并在传送到备库时重新装配。

DELAY

这个属性并不是像大多数想象的那样延迟重做数据的传输，它只是用来指示备库目标的日志应用进程在DELAY属性设置的时间(秒)后应用重做数据。有了闪回数据库，这个属性几乎被弃用，尤其在自从我们建议在主备库中一直启用闪回数据库功能后。如果你倾向于完成一些闪回数据库无法处理的任务量，则可能需要设置这个属性。

ALTERNATE

替代(ALTERNATE)目标最初的目的是，当正在归档ORL日志文件的磁盘空间已满时，保持数据库的持续运行。使用替代目标，你可以将归档日志文件重定向到一个备用磁盘中。有了闪回恢复区(自动管理空间)，这个问题基本上消失了。

如果你有多个指向备库的网络路径，也可以为远程备用目标使用该属性。显然，你会在RAC环境中使用多个备库网络路径，但是这并不是ALTERNATE属性设计的初衷。对于有着多网卡的单实例或者RAC的环境，在备库的TNS描述符中使用connect-time failover会更简便。

3.建议不要使用的属性

LOCATION

在10gR2之前，该属性必须指定一个文件位置用于归档进程存储归档日志文件，并且这在主库(对于ORL文件)和备库(对于SRL文件)确实是正确的。不过随着闪回恢复区和默认本地归档的使用，这个属性已经不再需要设置了。编号为10的目标将自动设置成闪回恢复区。

MANDATORY

这是备库上最危险的属性之一。基本上，它规定ORL文件中的redo信息必须发送到该备库。如果redo信息无法发送到备库，那么主库中包含redo信息的这个ORL文件在成功发送到备库之前将无法被重用(reuse)。试想当备库无法访问并且主库中所有可用的日志文件都被遍历完了，那么生产系统就会停滞。当然，有一个本地目标是MANDATORY的以使文件存放在磁盘上，不过没有必要再设置另一个了。默认情况下，本地归档中的一个目标会被设置成MANDATORY。

MAX_FAILURE

这个属性是所有属性中最遭人误解的一个。人们都倾向与认为这个属性表示LGWR进程在放弃发生故障的备库并继续产生日志之前，重新连接备库的次数。事实并非如此，如果你设置了该属性，实际是定义了LGWR尝试重连有故障的备库时，日志组切换的次数(注：原文写的更加让人容易误解，这里的意思就是切换一次日志，重连一次备库)。举例来说，如果将MAX_FAILURE的值设置成5，那么LGWR将会在它循环切换日志期间对故障备库总共发起5次连接请求，如果切换了5次还是无法连接到故障备库，那么LGWR将放弃重连，之后你要么等手动重新启用它或者等主库重启重新生效该属性。

NOREGISTER

这是我们讨论的LOG_ARCHIVE_DEST_n参数的最后一个属性。默认情况下，DG要求任何发送到备库的redo数据都需要在归档至磁盘的时候完成对备库的注册。对于一个物理备库来说，意味着数据会被注册到备库的控制文件中；而对于逻辑备库来说，它意味着SQL Apply会在元数据中注册日志文件。DG不需要这个属性，它可以用在使用downstream特性的Streams目标库中。

⏹LOG_ARCHIVE_DEST_STATE_n

这是和LOG_ARCHIVE_DEST_n配套使用的参数。在过去，有两个原因我们需要配置它。一是启用备库中主角色LOG_ARCHIVE_DEST_n参数的预定义，以使得该参数被启用后归档进程可以使用LOG_ARCHIVE_DEST_n来工作；另一个原因是配置一个如前面所述的ALTERNATE目标。第一个原因已经没有作用了(现在使用了VALID_FOR)，并且除非你使用ALTERNATE属性，否则第二个原因也不成立了，因为现在这个参数默认就是ENABLE的了，你不再需要为你的目标库设置它了。

备库参数

⏹DB_FILE_NAME_CONVERT

在备库中，该参数允许你逻辑上将数据文件从主库迁移到备库上，如果你使用的是基于磁盘的存储结构并且存储路径在两个系统上并不相同，那么就有必要配置它。只有在备库切换为主库这期间，该转换才会执行。一旦进行主备切换或者故障转移到备库，这些值就会被写入到控制文件和数据文件头。通过简单的字符替换就可以实现功能。

⏹LOG_FILE_NAME_CONVERT

功能和DB_FILE_NAME_CONVERT参数相同，只不过这里转换的是日志文件，包括ORL文件和任何SRL文件。

⏹FAL_SERVER

FAL(Fetch Archive Log)功能相比9iR1时的DG已经有了很大的进步。它只用于物理备库，配置它能够使得物理备库在发现问题时，从DG配置中的一个数据库(主库或备库)中获取缺失的归档日志文件，有时我们又成它为被动间隔处理(reactive gap resolution)，不过FAL技术在之前的三个版本中得到了极大的增强以至于现在几乎不需要再定义FAL参数了。伴随着9iR2版本引入的主动间隔处理(proactive gap resolution)技术的使用，几乎物理或逻辑备库上任何类型的间隔请求都可以由主库上的ping进程来处理了。

在主库的正常工作过程中，归档进程(被指定为ping进程)会轮流查询所有的备库来寻找redo间隔，与此同时处理任何应用进程发来的未解决的间隔请求。当物理备库需要从主库之外的数据库中获得间隔文件时就可以使用FAL技术。举个例子，比如物理备库现在需要进行间隔处理，但是主库无法访问，那么它需要去请求其他的备库来完成间隔处理，为此，你要将FAL_SERVER参数定义为指向主库或者任意备库的TNS标识符列表。如在orcl_2库中加入主库(orcl)和其他备库(orcl_3)：

SQL> ALTER SYSTEM SET fal_server='orcl, orcl_3' SCOPE=BOTH;

⏹FAL_CLIENT

FAL客户端，就是发起间隔请求的数据库的TNS名称，间隔请求的接收方(FAL_SERVER)需要这个TNS名称以使得FAL服务器上的数据库可以反向连接至请求方。在备库orcl_2上，我们发送orcl_2作为客户端名称以便orcl和orcl_3库可以连接回orcl_2库发送缺失的归档日志文件。

SQL> ALTER SYSTEM SET fal_client='orcl_2'

 ‘orcl_2’必须要在FAL服务器的TNS文件中定义以使得DG能够成功连接备库；因为我们将会在所有这些数据库中设置redo传输参数，所以我们也要为它们配置TNS名称。如果你在FAL参数中使用相同的TNS名称，那么这些TNS名称就是定义好的了。如果你选择了一个不同的名称，你就需要在所有系统的TNS文件中添加这个名称。和FAL_SERVER参数一样，FAL_CLIENT参数只对物理备库有效。

⏹STANDBY_FILE_MANAGEMENT

这个参数只用于物理备库。该参数设置成AUTO的时候，主库中添加和删除数据文件的同时，备库中也会自动的进行相应的更改。只要备库中顶级目录存在或能够借助于DB_FILE_NAME_CONVERT参数找到，那么DG将会执行DDL语句在备库中创建数据文件。它甚至会尽可能的创建缺失的子目录。默认情况下，这个参数的值为MANUAL，这意味着备库上的应用进程不会创建新的数据文件，你需要手动创建它们。

SQL> ALTER SYSTEM SET standby_file_management='AUTO' SCOPE=BOTH;

只有当需要对物理备库上的ORL文件执行定义操作的时候，我们才可能会将该参数设置成MANUAL。SRL文件能够在不改这个参数的情况下添加。如果你真要在物理备库上添加或删除在线日志文件(比如因为主库上发生了更改)，你也可以将这个参数动态的设置成MANUAL，执行DDL操作，然后再还原成AUTO值，无需重启备库。

2.2环境介绍

主库环境

本教程使用RMAN的DUPLICATE方式创建备库。

主库配置

在主机HOST-ORACLE-PR上安装数据库软件（仅安装数据库软件，不建库）

在D盘创建目录d:\\datafile，用来存放系统文件，包括：联机日志文件，撤销表空间数据文件，临时表空间数据文件和系统表空间数据文件

在D盘创建目录d:\\recovery，做为闪回恢复区

在E盘创建目录e:\crm，用来存放用户数据文件

运行oracle网络配置助手（Oracle Net Configuration Assistant）添加监听程序，所有选项保持默认即可

运行数据库配置助手（DBCA，Database Configuration Assistant）创建数据库

设置DB_NAME（全局数据库名），SID（Oracle系统标识符）的值为crm

选择d:\\datafile做为数据库文件位置

选择d:\\recovery做为闪回恢复区位置，将其大小设置为40G

在“初始化参数”配置页打开“所有初始化参数”，将DB_UNIQUE_NAME修改为crm_primary

选择所有账户使用同一管理口令q1w2e3r4

打开SQLPLUS，使用命令行创建用户表空间并添加数据文件，之后创建用户并进行授权

C:\\> SQLPLUS /NOLOG

SQL> CONN / AS SYSDBA

SQL>CREATE SMALLFILE TABLESPACE "CRM" DATAFILE'e:\\crm\\crm01.dbf' SIZE 5G AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED,'e:\\crm\\crm02.dbf' SIZE 5G AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED LOGGINGEXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

SQL> CREATE USER "CRM" PROFILE "DEFAULT" IDENTIFIED BY "crmforolap" DEFAULT TABLESPACE "CRM" TEMPORARY TABLESPACE "TEMP" ACCOUNT UNLOCK;

SQL> GRANT "CONNECT" TO "CRM";

SQL> GRANT "DBA" TO "CRM";

此时主库数据库和用户表空间已经创建成功，但用户表空间并无数据，可使用expdp/impdp从生产库导出一份数据到本库，也可自行建立测试数据。

开启数据库归档模式，启用强制日志记录功能和数据库闪回功能

SQL>SHUTDOWN IMMEDIATE

SQL>STARTUP MOUNT

SQL>ALTER DATABASE ARCHIVELOG;

SQL>ALTER DATABASE FORCE LOGGING;

SQL>ALTER DATABASE FLASHBACK ON;

SQL>ALTER DATABASE OPEN;

归档模式和强制日志记录功能为DataGuard必须，强烈建议开启数据库闪回功能。闪回允许你将数据库还原到以前的某一时间点。当发生故障转移时，这个功能非常有用，它能让你将老的主库闪回到故障前，然后将其转换为备库。如果没有启用闪回功能，你就必须重建备库，意味着要再复制一次数据文件。除了这个好处，闪回还能在某些情况下让你避免从备份恢复数据。在主库启用闪回日志，不会同步备库也启用。你必须手动在主库和备库上均启用闪回日志。

配置静态监听，修改监听程序配置文件listener.ora，加入以下内容：

(SID_DESC =

      (SID_NAME = crm)

      (ORACLE_HOME = D:\\app\\Administrator\\product\\11.2.0\\dbhome_1)

      (GLOBAL_DBNAME = global_crm_pr)

      (ENVS = "EXTPROC_DLLS=ONLY:D:\\app\\Administrator\\product\\11.2.0\\dbhome_1\\bin\\oraclr11.dll")

)

修改客户端连接配置文件tnsnames.ora，加入以下内容：

SERVICE_CRM_PR =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.10.16)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = global_crm_pr)

    )

  )

SERVICE_CRM_ST =

  (DESCRIPTION =

    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.20.24)(PORT = 1521))

    (CONNECT_DATA =

      (SERVER = DEDICATED)

      (SERVICE_NAME = global_crm_st)

    )

  )

重启

C:\>LSNRCTL STOP

C:\>LSNRCTL START

设置归档日志本地位置（可选）

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_1 = 'location=USE_DB_RECOVERY_FILE_DESTvalid_for=(all_logfiles, all_roles) db_unique_name=crm_primary';

说明：这个命令指定快速恢复区作为归档位置，此归档位置用于在所有数据库角色下归档所有的日志文件。官方文档里说使用valid_for=(online_logfiles, all_roles)，这将导致备库无法归档备用日志文件，因为它们不是在线日志。但如果使用all_logfiles选项，主备库将都能归档在线以及备用日志。如果你想在备库进行备份，并同时备份归档日志的话，必须使用all_logfiles（Oracle 11g的LOG_ARCHIVE_DEST_1参数默认指向闪回恢复区，本步骤可省略）。

定义DataGuard可用的DB_UNIQUE_NAME值列表

SQL> ALTER SYSTEM SET LOG_ARCHIVE_CONFIG = 'dg_config=(crm_primary,crm_standby)';

说明：该参数定义了DataGuard配置中可用的DB_UNIQUE_NAME参数值列表，与目标参数DB_UNIQUE_NAME的值结合使用时，DataGuard用它们来实现两个数据库之间连接的安全性检查工作。

设定归档日志远程目标

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_2 ='SERVICE=service_crm_st async valid_for=(online_logfile,primary_role) db_unique_name=crm_standby';

说明：将参数LOG_ARCHIVE_DEST_2设定为远程备库，只有角色为主库且为在线重做日志时有效。其中属性SERVICE的值（service_crm_st）为指向备库的连接描述符别名，在主库的客户端连接配置文件tnsnames.ora中定义。属性db_unique_name的值为备库唯一名称。

tnsnames.ora文件中的SERVICE_NAME参数对应备库服务器监听程序配置文件listener.ora中的GLOBAL_DBNAME参数，两者取值必须一致。

创建静态参数文件和口令文件

SQL> CREATE PFILE FROM SPFILE;

C:\\> ORAPWD FILE=%ORACLE_HOME%\database\PWDcrm.ora PASSWORD=q1w2e3r4

说明：静态参数文件默认创建位置为%ORACLE_HOME%\\database，必须手动创建；口令文件默认已经在此目录生成，可不用创建。

至此，DataGuard主库配置完成。

备库配置

在主机HOST-ORACLE-ST上安装数据库软件（仅安装数据库软件，暂不创建数据库）；

在F盘创建目录f:\\datafile\\crm_standby，用来存放系统数据文件，包括：联机日志文件，撤销表空间数据文件，临时表空间数据文件和系统表空间数据文件；

在F盘创建目录f:\\recovery\\crm_standby，做为闪回恢复区；

在F盘创建目录f:\crm，用来存放用户数据文件；

在F盘创建目录f:\\controlfile_01，f:\\controlfile_02，用来存放控制文件；

在F盘创建目录f:\\standby_log，用来存放备用联机日志文件；

运行oracle网络配置助手（Oracle Net Configuration Assistant）添加监听程序，所有选项保持默认即可；

使用oradim创建oracle实例crm：

C:\\>oradim -new –sid crm

添加系统环境变量ORACLE_SID并将变量值设置为crm；

将主库创建的静态参数文件INITcrm.ora和口令文件PWDcrm.ora复制到备库%ORACLE_HOME%\\DATABASE目录下，根据备库环境对INITcrm.ora进行编辑

1.修改以下项

*.audit_file_dest='d:\\app\\Administrator\\admin\\crm_primary\\adump'

*.audit_file_dest='d:\\app\\Administrator\\admin\crm_standby\\adump'

*.control_files='d:\\datafile\\crm_primary\\control01.ctl','D:\\recovery\\crm_primary\\control02.ctl'

*.control_files='f:\\controlfile_01\\control01.ctl','f:\\controlfile_02\\control02.ctl'

*.db_recovery_file_dest='D:\\recovery'

*.db_recovery_file_dest='f:\\recovery'

*.db_unique_name='crm_primary'

*.db_unique_name='crm_standby'

2.新增以下项

*.standby_file_management='AUTO'

*.fal_server='service_crm_pr'

*.db_file_name_convert='d:\\datafile\\crm_primary\','f:\\datafile\\crm_standby\','d:\\recovery\\crm_primary\','f:\\recovery\\crm_standby','e:\\crm\','f:\\crm\'

*.log_file_name_convert='d:\\datafile\\crm_primary\','f:\\datafile\\crm_standby\'

参数说明：

*.control_files='f:\\controlfile_01\\control01.ctl','f:\\controlfile_02\\control02.ctl'

#参数，设置控制文件存放位置

*.audit_file_dest='d:\\app\\Administrator\\admin\crm_standby\\adump'

#参数，数据库审计文件位置

*.db_unique_name='crm_standby'

#参数，数据库唯一名称（必须与主库不同）

*.db_recovery_file_dest='f:\\recovery'

# 参数，闪回恢复区位置

*.fal_server='service_crm_pr'

#备库参数，设置缺失日志的查找位置。当日志传输出现问题时会出现日志缺口问题，备库会根据此参数主动请求重传，可设置为主库或其他备库的TNS描述符别名列表（必须设置）

*.STANDBY_FILE_MANAGEMENT = ‘AUTO’;

#备库参数，备库数据文件管理方式，修改为AUTO，当主库添加删除数据文件时，备库同样会进行添加删除。

*.db_file_name_convert=‘d:\\datafile\\crm_primary\’,’f:\\datafile\\crm_standby\’,’d:\\recovery\\crm_primary\’,’f:\\recovery\\crm_standby’,’e:\\crm\’,’f:\\crm\’

# 备库参数，当主库数据文件路径和备库不同时，用来进行路径转换（注意语法，路径后面要加“\”）。

*.log_file_name_convert=‘d:\\datafile\\crm_primary\’,’f:\\datafile\\crm_standby\’

# 备库参数，当主库日志文件路径和备库不同时，用来进行路径转换（注意语法，路径最后需要有“\”）。

复制主库listener.ora文件和tnsnames.ora文件到备库%ORACLE_HOME%\\NETWORK\\ADMIN目录，打开listener.ora文件，找到HOST = HOST-ORACLE-PR和GLOBAL_DBNAME = global_crm_pr两项，将其修改为：HOST = HOST-ORACLE-ST和GLOBAL_DBNAME = global_crm_st

重启

C:\>LSNRCTL STOP

C:\>LSNRCTL START

以NOMOUNT模式启动备库

C:\\> SQLPLUS /NOLOG

SQL> CONN / AS SYSDBA

SQL> STARTUP NOMOUNT PFILE=D:\\app\\Administrator\\product\\11.2.0\\dbhome_1\\database\INITcrm.ora

至此，DataGuard备库配置基本完成。

复制数据库

检查主备库之间网络连接是否正常（建议暂时关闭防火墙）；

在主库上打开RMAN管理器并连接到备库进行复制：

C:\>RMAN TARGET /    

RMAN> CONNECTION AUXILILARY sys/q1w2e3r4@service_crm_st

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY NOFILENAMECHECK FROM ACTIVE DATABASE;

注意：请仔细检查备库静态参数文件中对应的目录都存在，路径转换配置正确，否则会导致复制失败。

复制完成后在备库上打开SQLPLUS，添加4组备用重做日志

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 11 ('F:\\standby_log\\g11m01.dbf') SIZE 50M;

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 12 ('F:\\standby_log\\g12m01.dbf') SIZE 50M;

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 13 ('F:\\standby_log\\g13m01.dbf') SIZE 50M;

SQL>ALTER DATABASE ADD STANDBY LOGFILE GROUP 14 ('F:\\standby_log\\g14m01.dbf') SIZE 50M;

关闭备库再次启动

SQL>SHUTDOWN IMMEDIATE

SQL>STARTUP NOMOUNT STANDBY DATABASE

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

说明：备库以MOUNT模式打开，接收并应用主库发来的重做日志。

ORACLE 11g支持备库以只读模式打开的同时应用重做日志，基于上步状态进行以下操作：

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER DATABASE OPEN;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

2.4其他问题

静态参数文件中内存和进程相关配置

主备切换流程

审计文件路径

闪回功能开启

第3章 角色切换

3.1SwitchOver

准备工作

配置参数检查

文件系统检查

工作状态检查

主库切换为新备库

取消备库日志应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

确认主库switchover_status为"TO STANDBY"

SQL> SELECT database_role,switchover_status from V$DATABASE;

切换主库为新备库

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;

检查切换结果，确认database_role为"PHYSICAL STANDBY"

SQL> SELECT database_role, switchover_status from V$DATABASE;

备库切换为新主库

开启原备库日志应用

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

确认原备库switchover_status为"TO PRIMARY"

SQL> SELECT database_role,switchover_status from V$DATABASE;

切换原备库为新主库

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;

检查切换结果，确认database_role为"PRIMARY"

SQL> SELECT database_role, switchover_status from V$DATABASE;

新备库应用日志

新备库暂停远程归档

SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2='DEFER' SCOPE=BOTH;

新备库重启

SQL> SHUTDOWN IMMEDIATE

SQL> STARTUP

新备库应用日志

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;

3.2FailOver