11G_RAC_DG环境配置以及维护文档

11G_RAC_DG环境配置以及维护文档
Oracle_rac_11g下的DG搭建与维护
一．DG基础知识介绍
1.Data Guard结构
Data Guard是一个集合，由一个Primary数据库（生产数据库）及一个或多个Standby数据库（最多9个Standby）组成。

组成Data Guard的各个Oracle数据库之间，通过Oracle的网络服务名（Net Service Name）连接，并且有可能分布于不同地域，实
际上只要各库之间能够相互通信，它们的物理位置并没有什么限制，至于操作系统就
更无所谓了（某些情况下），只要支持安装Oracle数据库软件就行了。

1．Primary 数据库
Primary数据库在某些资料中也被称为主数据库，相同Data Guard环境中至少要包
含一个并且仅能有一个Primary数据库，实际上就是产生修改操作，并负责将这些操作传输到其他服务器的主数据库，该库既可以是单实例主数据库，也可以是RAC结构。

2．Standby 数据库
Standby数据库在某些资料中也被称为从数据库，或者备数据库。

Standby数据库
可以视作Primary数据库在某个时间点时的备份（事务上一致）。

在同一套Data Guard
配置中最多可以创建9个Standby数据库。

一旦创建完成，Data Guard通过在Standby
数据库端，应用Primary数据库生成的重做记录（REDO数据）的方式，自动维护每一
个Standby数据库。

Standby数据库同样既可以是单实例数据库，也可以是RAC结构。

Standby数据库通常分两类：逻辑Standby和物理Standby，如何区分？两类各有什么特点？如何搭建？这方面内容在后续章节会主要介绍，在这里呢三思先简单白活一下。

逻辑Standby。

就像请人帮你素描画像，基本器官是都会有的，这点你放心，但是
各器官位置啦，大小啦，肤色啦，就不一定跟你本人一致了。

具体到数据库，就是说
内容可能相同，但结构可能有差异。

物理Standby。

就像拿相机拍照，你长什么样，出来的照片就是什么样，眼睛绝对
在鼻子上头。

或者说就像你去照镜子，里外都是你，哇哈哈。

具体到数据库，就是不
仅文件的物理结构相同，甚至连块在磁盘上的存储位置都是一模一样的（默认情况下）。

为什么会这样呢？这事就得从同步的机制说起了。

虽然都是接收Primary数据库生
成的REDO，不过逻辑Standby接收后将其转换成SQL语句，然后在Standby数据库
上执行SQL语句实现同步，这种方式有一个专业名词叫SQL Apply。

物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现
同步，这种方式也有一个专业名词叫Redo Apply。

提示
不知道大家是否注意到形容词上的细节：对于相机拍照而言，有种傻瓜相机功能
强大而操作简便，而对于素描，即使是最简单的画法，也需要相当多的练习才能掌握。

这个细节是不是也说明逻辑Standby比物理Standby需要操作者拥有更多的操作技能呢？
2.Data Guard服务
Data Guard后台有一个非常严谨并且完善的机制，来确保Primary与Standby数据
库间的数据传输、日志应用、状态检查、角色切换等，后续章节将会详细介绍，这里
先简单描述一下几个大的服务，大家先有一个大致的概念即可。

1．REDO传输服务（Redo Transport Services）
Oracle通过RTS服务（即REDO传输服务）控制REDO数据，从Primary数据库
发送到其他一个或多个归档目标。

归档目标既可以指向本地路径，也可以指向一个远
端的Service Name。

最常见的启动数据库归档模式，就是设置一个本地的归档路径，
而架设Standby服务器，则是设置一个或多个远端的Service Name，通过这种方式发送Primary端生成的REDO数据。

该服务属于基础服务，主要任务如下：
按照即定配置传输REDO数据到Standby数据库。

处理由于网络中断等原因导致的归档中断（Gap）。

控制数据库的保护模式。

检查Standby端丢失或无效的归档，并自动尝试从其他Primary/Standby获取。

2．Log应用服务（Log Apply Services）LAS服务（即Log应用服务）主要用来应用REDO数据到Standby数据库，以保
持Standby数据库与Primary数据库的事务一致。

REDO数据既可以从Standby数据库端的归档文件中读取，也可直接应用Standby。

Redolog文件（如果实时应用打开了的话）。

前面也提到了，物理Standby和逻辑Standby在应用REDO数据时的处理方式完全
不同：
对于物理Standby，Data Guard使用Redo Apply技术，即通过标准的RECOVER方式应用REDO数据。

对于逻辑Standby，Data Guard使用SQL Apply技术，即首先将接收到的REDO数
据转换成SQL语句，然后执行SQL语句的方式应用REDO数据。

3．角色转换（Role Transitions）
一套DG环境中只有两种角色：Primary和Standby。

所谓角色转换就是让数据库在这两个角色中切换，切换也分两种：switchover 和failover。

switchover：Primary数据库和Standby数据库之间的角色切换，如将Primary数据
库转换成Standby数据库，将Standby数据库转换成Primary数据库（如果有多个Standby数据库，一次只能选择其中的一个），switchover可以确保不会丢失数据。

failover：当Primary数据库出现故障并且不能被及时恢复时，就需要通过failover
将DG配置的其中一个Standby数据库转换为新的Primary数据库。

在最大保护模式或
最高可用性模式下，failover也可以保证不会丢失数据。

3.三种保护模式
对于Data Guard而言，它提供了三种数据保护的模式。

切换说数据的保护模式，
可以使用以下命令：
alter database set standby database to maximize avaliability;
最大保护（Maximum Protection）。

这种模式能够确保绝无数据丢失。

要实现这一
步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至
少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。

如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary
数据库会被Shutdown。

最高性能（Maximum performance）。

这种模式在不影响Primary数据库性能前提下，提供最高级别的数据保护策略。

事务可以随时提交，当前Primary数据库的REDO 数据至少需要写入一个Standby数据库，不过这种写入可以是不同步的。

如果网络条件理想的话，这种模式能够提供类似最高可用性的数据保护，而仅对Primary数据库的性能有轻微影响。

这也是创建Standby数据库时，系统的默认保护模式。

最高可用性（Maximum availability）。

这种模式在不影响Primary数据库可用前提下，提供最高级别的数据保护策略。

其实现方式与最大保护模式类似，也是要求本地
事务在提交前必须至少写入一台Standby数据库的Standby Redologs中，不过与最大保
护模式不同的是，如果出现故障导致Standby数据库无法访问，Primary数据库并不会
被Shutdown，而是自动转为最高性能模式，等Standby数据库恢复正常之后，Primary
数据库又会自动转换成最高可用性模式。

最大保护及最高可用性至少需要一个Standby数据库REDO数据被同步写入。

三
种模式都需要指定LOG_ARCHIVE_DEST_n初始化参数。

LOG_ARCHIVE_DEST_n很重要，你看着很眼熟是吧，我保证，如果你完完整整学完Data Guard，你会对它更熟。

4.三种保护模式的详细介绍及配置说明
当某次事务处理对生产数据库中的数据作出更改时，Oracle数据库将在一个联机重做
日志文件中记录此次更改。

在DataGuard中可以配置写日志的这个过程，除了把日志记录
到本地的联机日志文件和归档日志文件中，还可以通过网络，把日志信息发送到远程的从
数据库服务器上。

A. 这个备用日志文件写入过程可以是实时、同步的，以实现零数据丢失（最
大保护模式）；
B. 也可以是异步的，以减少对网络带宽的压力（最大性能模式）；
C. 或者是异步和同步可以自动切换的模式（最大可用模式）。

当备份数据库接收到日志信息后，Data Guard可以自动利用日志信息实现数据与主数据库的实时同步。

当主数据库打开并处于活动状态时，备用数据库可以执行恢复操作，如果主数据库出现了故障，备用数据库即可以被激活并接管生产数据库的工作
4.1三种模式的配置
保护护模式在出现灾难时数据丢失的风险重做传输机制是否需要standby redo log 磁盘写入
最大保护：零数据丢失 LGWR SYNC YES AFFIRM
最高可用性：零数据丢失 LGWR SYNC YES AFFIRM
最高性能：最小数据丢失—通常为几秒 LGWR ASYNC 或
ARCH 可没有但推荐有 AFFIRM or NOAFFIRM
4.2保护模式的参数说明AFFIRM.SYNC.LGWR
AFFIRM（磁盘写操作）：保证重做日志被写进物理备用数据库。

默认是NOAFFIRM。

Affirm是保证日志已经写到备库地址。

当使用lgwr,sync,affirm属性的时候需要直到IO全部完成事务才能提交。

该参数对数据库性能是有影响的。

Noaffirm就是说LGWR的IO操作是异步的，该参数是默认值。

表示主数据库上的REDO LOG只有被写入到从数据库的standby log才算有效
ARCH/LGWR（进程）：设置是archiver还是lgwr进程去负责从主库传输日志到备库节点，默认是archiver进程。

Arch含义就是在归档期间对日志进行传输。

充当传输服务功能的可以是后台的归档进程，也可以是前台手工归档的一条SQL。

LGWR含义就是当LGWR写联机日志的时候，同时将日志写进备
库重做日志。

LGWR就是日志传输服务进程。

当LGWR传输日志到远程地点的时候，LGWR同远程数
据库实例建立一个连接，如果建立连接失败，那么会自动启用归档进程，直到能够成功建
立连接。

SYNC/ASYNC（网络传输模式）:当使用LGWR进程去传递日志的时候，网络IO同步还
是异步的。

默认是同步的，并且有并行属性。

SYNC含义就是网络IO与目的地是同步的。

也就是说每当启动一个IO时，LGWR会
等待该IO完成才能继续处理。

当需要建立无数据损失的环境的时候，需要指定Sync属性，因为该属性可以保证日志信息准确的传输到了备库节点。

当使用LGWR传输日志的时候，如果有多个备库节点，当设置SYNC=NOPARALLE，那么LGWR必须等待一个目的地址的IO完成才能写下一个IO地址，也就是每个地址是顺序写的。

如果指定SYNC=PARALLE，其实IO就是异步的，也就是多个目的地址可以同时进行IO操作，但是同样，LGWR也需要等待每个目的地的IO 完成后才能继续处理。

ASYNC[=blocks] (默认值是2048，块的个数)，指定为每个地址异步执行IO。

LGWR
不检查本次IO操作是否完成，直接可以继续处理下一个IO请求。

使用异步IO可以使备
库的环境对主库性能影响最小。

2048是指在SGA中网络缓冲的大小。

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

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

强烈建议，这种模式应至少配置两个备用数
据库。

当最后参与的备用数据库不可用时，主数据库上的处理将停止。

这就确保了当主数
据库与其所有备用数据库失去联系时，不会丢失事务。

由于重做传输的同步特性，这种最大保护模式可能潜在地影响主数据库响应时间。

可以通
过配置一个低延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影响减到最小。

需要这种最大保护模式的企业有股票交易所、货币交易所、金融机构等。

最高可用性模式
最高可用性模式拥有仅次于最高水平的主数据库数据可用性。

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

不过，在这种模式下（与最大保护模式不同），如果最后参与的备用数据库变为不可用—例如由于网络连接问题，处理将在主数
据库上继续进行(类似于MySQL-5.5中的半同步复制)。

备用数据库与主数据库相比，可能
暂时落在后面，但当它再次变为可用时，备用数据库将使用主数据库上累积的归档日志自
动同步，而不会丢失数据。

由于同步重做传输，这种保护模式可潜在地影响响应时间和吞吐量。

可以通过配置一个低
延迟网络，并为它分配足够应付高峰事务负载的带宽来将这种影
响减到最小。

最高可用性模式适用于想要确保获得零数据丢失保护，但不想让生产数据库受网络/备用服
务器故障影响的企业。

如果又一个故障随后影响了生产数据库，然后最初的网络/备用服务
器故障得到解决，那么这些企业将接受数据丢失的可能性。

最高性能模式
最高性能模式是默认的保护模式。

它与最高可用性模式相比，提供了稍微少一些的主数据
库数据保护，但提供了更高的性能。

在这种模式下，当主数据库处理事务时，重做数据由LGWR 进程异步传输到备用数据库上。

另外，也可以将主数据库上的归档器进程(ARCH) 配置为在这种模式下传输重做数据。

在任何情况下，均先完成主数据库上的写操作，主数据库的提交操作不等待备用数据库确认接收（类似于MySQL中的异步复制）。

如果任意备用目标数据库变为不可用，则处理将在主数据库上继续进行，这对性能只有很小的影响或没有影响。

在主数据库出现故障的情况下，尚未被发送到备用数据库的重做数据会丢失。

但是，如果网络有足够的吞吐量来跟上重做流量高峰，并且使用了LGWR 进程来将重做流量传输到备用服务器，则丢失的事务将非常少或者为零。

4.4 DataGuard的过程介绍
从上图，我们可以很清晰的发现DataGuard和没MySQL 中的复制有很大的相似之处。

Redo Transport Services：自动的把主数据库上的Redo Log传输到从数据库上，可以是LGWR 进程也可以是ARCH 进程，所以重点要关注LOG_ARCHIVE_DEST的配置！Apply Services：从数据库将接受到的Redo Log进行Apply。

这里分为两种情况，一种是实时，一种是非实时的。

实时的是：只要从数据库接受到主数据库传输过来的Redo Log，就马上执行之。

实时的话，从数据库上面必须创建standby redo log。

非实时：对于主数据库传输过来的Redo Log，并不会马上执行，
而是在主数据库上的在线日志归档之后才会执行之，非实时是默认情况。

standby redo log:其实就是在从库上的主库的日志，对于最大可用和最大保护模式，会先写到standby redo log中。

下面是官方最为权威的解释。

A standby redo log is similar to an online redo log, except that a standby redo log is used to store redo data received from another database.
A standby redo log is required if you want to implement:
1、The maximum protection and maximum availability levels of data protection
2、Real-time apply (If the real-time apply feature is enabled, log apply services can apply redo data as it is received, without waiting for the current standby redo log file to be archived. This results in faster switchover and failover times because the standby redo log files have been applied already to the standby database by the time the failover or switchover begins.
3、Cascaded destinations (To reduce the load on your primary system, you can implement cascaded destinations, whereby a standby database receives its redo data from another standby database, instead of directly from the primary database.)
A standby redo log provides a number of advantages:
1、Standby redo log files can reside on raw devices, which may be important if either or both the primary and standby databases reside in a Real Application Clusters environment.
2、Standby redo log files can be multiplexed using multiple members, improving reliability over archived log files.
3、During a failover, Data Guard can recover and apply more redo data from standby redo log files than from the archived log files alone.
4、The archiver (ARCn) process or the log writer (LGWR) process on the primary database can transmit redo data directly to remote standby redo log files, potentially eliminating the need to register a partial archived log file (for example, to recover after a standby database crashes)
standby redo log创建的原则：
standby redo log最好在主从数据库上都创建，这样方便主从数据库切换
standby redo log的文件大小与primary 数据库online redo log 文件大小相同
standby redo log日记文件组的个数依照下面的原则决定
Standby redo log组数公式>=(每个instance日记组个数+1)*instance个数
假设有一个节点，这个节点有三组redo log，那么 Standby redo log组数公式>=(3+1)*1=4，所以需要创建4组Standby redo log，多实例主要是在RAC 环境下。

4.Data Guard特点总结
Data Guard特点如下：
灾难恢复及高可用性。

全面的数据保护。

有效利用系统资源。

在高可用及高性能之间更加灵活的平衡机制。

故障自动检查及解决方案。

集中的易用的管理模式。

自动化的角色转换。

二、DG配置
配置oracle rac的dg环境说白了首先将主库的数据恢复到从库上，然后在主从库上配置一些DG需要用到的参数，说起来挺简单的，那具体的实施过程以我们测试环境搭
建的一套环境作为实例进行说明
1．机器环境
1.由于DG是以DB_UNIQUE_NAME作为区分数据库标识的，因此主从库的该参
数一定要不同以做区分。

但是数据库名db_name必须一致以便主从切换时方
便
2.Standby库只需要安装数据库软件，不必创建数据库
3.主从库的数据库软件大版本必须一致，且必须是企业版数据库EE
2．启动主库归档模式
建议不要将归档路径设置到flash_recovery_area，而设置到普通目录
SQL>alter system set
log_archive_dest_1='LOCATION=/dats/app/oracle/product/ 11g/ora data' scope=spfile;
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 126
Next log sequence to archive 127
Current log sequence 127
SQL> show parameter recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string +ORAFLASH
db_recovery_file_dest_size big integer 3882M
recovery_parallelism integer 0
如果数据库未开启归档，则需开启归档模式（mount状态下）
SQL>alter database archivelog
启动主库force_logging模式
SQL> alter database FORCE LOGGING;
Database altered.
SQL> select FORCE_LOGGING from v$database;
FOR
---
YES
3. 配置主库和从库的tnsnames.ora
增加以下配置
racheren1 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac1-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racheren)
(INSTANCE_NAME = racheren1)
)
)
racheren2 =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = rac2-vip)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racheren)
(INSTANCE_NAME = racheren2)
)
)
RACHEREN =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
10.10.77.37)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST =
10.10.77.39)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racheren)
)
)
RACHEREN_STANDBY =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST =
10.10.77.47)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racheren)
)
)
4. 配置主从库的listener.ora
按照以下内容配置从库的监听文件，然后启动监听程序。

由于dg 主从库是以GLOBAL_NAME作为区分，因此配置主从库GLOBAL_NAME不同，以做区分，在后面的SPFILE中有说明.务必严格按照此listenser配置：
$ORACLE> lsnrctl start
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = dg_standby)
(ORACLE_HOME = /dats/app/oracle/product/11g/db)
(SID_NAME = ogg1)
)
(SID_DESC =
(GLOBAL_DBNAME = PLSExtProc)
(ORACLE_HOME = /dats/app/oracle/product/11g/db)
(SID_NAME = PLSExtProc)
)
(SID_DESC=
(SID_NAME=ogg1)
(ORACLE_HOME=/dats/app/oracle/product/11g/db)
)
)
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST =
10.10.77.47)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC0))
)
)
5.准备主库的参数文件
RAC环境的参数文件配置如下（注意使用ASM的时候，不要改变db_unique_name参数，否则新建的asm文件会放入新的db_unique_name目录下面，导致
db_file_name_convert失效），这里我们保持主RAC库的db_unique_name与数据库名一致
#add below parameter for standy database这个分隔符以上的参数为数据库本身的参数取自rac数据库本身而不做改变，只增加分隔符以下的DG参数
注意：在DG的配置中，主从的概念是相对的。

比如A和B，那么配置A时，A是从机client，B就是主机server；配置B时，B是从机client，A就是主机server
DB_UNIQUE_NAME 指定实例的唯一标识，与rac的db_name 保持一致
DB_FILE_NAME_CONVERT数据库文件转换，包括datafile和tempfile，顺序为：主从LOG_FILE_NAME_CONVERT日志转换，包括onlinelog和archivelog，顺序为：主从注意：*.LOG_ARCHIVE_DEST_1参数指定的是本地的归档路径，同时*.LOG_FILE_NAME_CONVERT将本地的归档日志传送到从节点上。

如果将DEST的路径设置到db_recovery_file_dest的话，在配置ogg时会出现归档文件为arc 而查找文件名为dbf的问题，此处建议配置归档路径不要设置到
db_recovery_file_dest目录
racheren2.__db_cache_size=436207616
racheren1.__db_cache_size=369098752
racheren2.__java_pool_size=16777216
racheren1.__java_pool_size=16777216
racheren2.__large_pool_size=16777216
racheren1.__large_pool_size=16777216
racheren1.__oracle_base='/dats/app/oracle/product/11g'#O RACLE _BASE set from environment
racheren2.__oracle_base='/dats/app/oracle/product/11g'#O RACLE _BASE set from environment
racheren2.__pga_aggregate_target=671088640
racheren1.__pga_aggregate_target=671088640
racheren2.__sga_target=989855744
racheren1.__sga_target=989855744
racheren2.__shared_io_pool_size=0
racheren1.__shared_io_pool_size=0
racheren2.__shared_pool_size=503316480
racheren1.__shared_pool_size=570425344
racheren2.__streams_pool_size=0
racheren1.__streams_pool_size=0
*.audit_file_dest='/dats/app/oracle/product/11g/admin/rac heren/ad ump'
*.audit_trail='db'
*.cluster_database=true
*.compatible='11.2.0.0.0'
*.control_files='+ORADATA/racheren/controlfile/current.260 .81134
9567','+ORAFLASH/racheren/controlfile/current.256.811349569' *.db_block_size=8192
*.db_create_file_dest='+ORADATA'
*.db_domain=''
*.db_name='racheren'
*.db_recovery_file_dest='+ORAFLASH'
*.db_recovery_file_dest_size=4070572032
*.diagnostic_dest='/dats/app/oracle/product/11g'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=racherenXDB)' racheren1.instance_number=1
racheren2.instance_number=2
racheren1.local_listener='(DESCRIPTION=(ADDRESS_LIST=( AD
DRESS=(PROTOCOL=TCP)(HOST=10.10.77.37)(PORT=1521))))' racheren2.local_listener='(DESCRIPTION=(ADDRESS_LIST=( AD
DRESS=(PROTOCOL=TCP)(HOST=10.10.77.39)(PORT=1521))))' *.log_archive_format='%t_%s_%r.dbf'
*.memory_target=1655701504
*.nls_language='ENGLISH'
*.nls_territory='CHINA'
*.open_cursors=300
*.processes=1500
*.remote_listener='scan-vip:1521'
*.remote_login_passwordfile='exclusive'
*.sessions=1655
racheren2.thread=2
racheren1.thread=1
racheren1.undo_tablespace='UNDOTBS1'
racheren2.undo_tablespace='UNDOTBS2'
#add below parameter for standy database
*.service_names=racheren
*.DB_UNIQUE_NAME=racheren
*.LOG_ARCHIVE_CONFIG='DG_CONFIG=(racheren,racheren_ st andby)'
*.LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_ FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES)
DB_UNIQUE_NAME=racheren'
*.LOG_ARCHIVE_DEST_2='SERVICE=racheren_standby LGWR VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
DB_UNIQUE_NAME=racheren_standby'
*.FAL_SERVER='racheren_standby'
*.FAL_CLIENT='racheren'
*.STANDBY_FILE_MANAGEMENT=AUTO
*.DB_FILE_NAME_CONVERT='/dats/app/oracle/product/11g /orad
ata/datafile','+ORADATA/racheren/datafile','/dats/app/oracle/pr odu ct/11g/oradata/tempfile','+ORADATA/racheren/tempfile' *.LOG_FILE_NAME_CONVERT='/dats/app/oracle/product/11 g/arc
hivelog','+ORAFLASH/racheren/archivelog','/dats/app/oracle/pr odu
ct/11g/onlinelog','+ORADATA/racheren/onlinelog','/dats/app/or acle/ product/11g/onlinelog','+ORAFLASH/racheren/onlinelog' racheren1.fal_client='racheren1'
racheren2.fal_client='racheren2'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
6.准备从库的参数文件
从库的控制文件中，由于从库会切成主库，而对应的rac主库会变为从库，这时需要关闭rac的一个节点，并将日志传送到rac存活的节点上。

所以从库中配置主库的信息为一个节点，例如racheren1,参见下列参数的标红地方
#add below parameter for standy database
*.audit_file_dest='/dats/app/oracle/product/11g/admin/rac
heren/ad ump'
*.background_dump_dest='/dats/app/oracle/product/11g/a dmin/rac heren/bdump'
*.compatible='11.2.0.1.0'
*.control_files='/dats/app/oracle/product/11g/oradata/data file/rache ren.ctl'
*.core_dump_dest='/dats/app/oracle/product/11g/admin/r acheren/c dump'
*.db_block_size=8192
*.db_domain=''
*.db_name='racheren'
*.DB_UNIQUE_NAME='racheren_standby'
*.db_file_multiblock_read_count=18
*.DB_FILE_NAME_CONVERT='+ORADATA/racheren/datafile', '/da
ts/app/oracle/product/11g/oradata/datafile','+ORADATA/racher en/t empfile','/dats/app/oracle/product/11g/oradata/tempfile' *.fal_client='racheren_standby'
*.FAL_SERVER='racheren1',’racheren2’
*.job_queue_processes=1000。