一． Data Guard 架构

DG架构可以按照功能分成3个部分：

1） 日志发送（Redo Send）

2） 日志接收（Redo Receive）

3） 日志应用（Redo Apply）

 

1. 日志发送（Redo Send）

Primary Database 运行过程中，会源源不断地产生Redo 日志，这些日志需要发送到Standy Database。 这个发送动作可以由Primary Database 的LGWR 或者ARCH进程完成， 不同的归档目的地可以使用不同的方法，但是对于一个目的地，只能选用一种方法。 选择哪个进程对数据保护能力和系统可用性有很大区别。

 

1.1 使用ARCH 进程

1）Primary Database 不断产生Redo Log，这些日志被LGWR 进程写到联机日志。

2）当一组联机日志被写满后，会发生日志切换（Log Switch），并且会触发本地归档，本地归档位置是采用 LOG_ARCHIVE_DEST_1='LOCATION=/path' 这种格式定义的。

如：alter system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;

3）完成本地归档后，联机日志就可以被覆盖重用。

4）ARCH 进程通过Net 把归档日志发送给Standby Database的RFS（Remote File Server） 进程。

5）Standby Database 端的RFS 进程把接收的日志写入到归档日志。

6）Standby Database 端的MRP(Managed Recovery Process)进程（Redo Apply）或者LSP 进程（SQL Apply）在Standby Database上应用这些日志，进而同步数据。

 

用ARCH模式传输不写Standby Redologs，直接保存成归档文件存放于Standby端。

 

说明：

逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply。

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

 

注意：创建逻辑Standby数据库要先创建一个物理Standby数据库，然后再将其转换成逻辑Standby数据库。

 

 

使用ARCH进程传递最大问题在于： Primary Database 只有在发生归档时才会发送日志到Standby Database。 如果Primary Database 异常宕机，联机日志中的Redo 内容就会丢失，因此使用ARCH 进程无法避免数据丢失的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR 又分SYNC（同步）和ASYNC（异步）两种方式。

 

在缺省方式下，Primary Database使用的是ARCH进程，参数设置如下：

alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

 

1.2 使用LGWR 进程的SYNC 方式

1）Primary Database 产生的Redo 日志要同时写道日志文件和网络。也就是说LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），再由LNSn（LGWR Network Server process）进程把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。

2）LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这也是SYNC的含义所在。

3）Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。

4）Primary Database的日志切换也会触发Standby Database 上的日志切换，即Standby Database 对Standby Redo Log的归档，然后触发Standby Database 的MRP或者LSP 进程恢复归档日志。

 

因为Primary Database 的Redo 是实时传递的，于是Standby Database 端可以使用两种恢复方法：

实时恢复（Real-Time Apply）： 只要RFS把日志写入Standby Redo Log 就会立即进行恢复；

归档恢复： 在完成对Standby Redo Log 归档才触发恢复。

 

Primary Database默认使用ARCH进程，如果使用LGWR进程必须明确指定。使用LGWR SYNC方式时，可以同时使用NET_TIMEOUT参数，这个参数单位是秒，代表如果多长时间内网络发送没有响应，LGWR 进程会抛出错误。 示例如下：

alter system set log_archive_dest_2 = 'SERVICE=ST LGWR SYNC NET_TIMEOUT=30' scope=both;

 

1.3 使用LGWR进程的ASYNC 方式

使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。 它的工作机制如下：

1） Primary Database 一段产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。

2） LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送。

3） Primary Database的Online Redo Log 写满后发生Log Switch，触发归档操作，也触发Standby Database对Standby Database对Standby Redo Log 的归档；然后触发MRP或者LSP 进程恢复归档日志。

 

因为LGWR进程不会等待LNSn进程的响应结果，所以配置LGWR ASYNC方式时不需要NET_TIMEOUT参数。示例如下：

alter system set log_archive_dest_2 = 'SERVICE=ST LGWR ASYNC ' scope=both;

 

2. 日志接收（Redo Receive）

Standby Database 的RFS（Remote File Server）进程接收到日志后，就把日志写到Standby Redo Log或者Archived Log文件中，具体写入哪个文件，取决于Primary 的日志传送方式和Standby database的位置。如果写到Standby Redo Log文件中，则当Primary Database发生日志切换时，也会触发Standby Database上的Standby Redo Log 的日志切换，并把这个Standby Redo Log 归档。 如果是写到Archived Log，那么这个动作本省也可以看作是个归档操作。

在日志接收中，需要注意的是归档日志会被放在什么位置：

1） 如果配置了STANDBY_ARCHIVE_DEST 参数，则使用该参数指定的目录。

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

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

4） 如果STANDBY_ARCHIVE_DEST 和 LOG_ARCHIVE_DEST_n 参数都没有配置，使用缺省的STANDBY_ARCHIVE_DEST参数值，这个缺省值是$ORACLE_HOME/dbs/arc.

 

3. 日志应用（Redo Apply）

日志应用服务，就是在Standby Database上重演Primary Database日志，从而实现两个数据库的数据同步。 根据Standby Database重演日志方式的不同，可分为物理Standby（Physical Standby） 和 逻辑Standby（Logical Standby）。

Physical Standby 使用的是Media Recovery 技术，在数据块级别进行恢复，这种方式没有数据类型的限制，可以保证两个数据库完全一致。 Physical Standby数据库只能在Mount 状态下进行恢复，也可以是打开，但只能已只读方式打开，并且打开时不能执行恢复操作。

Logical Standby 使用的是Logminer 技术，通过把日志内容还原成SQL 语句，然后SQL引擎执行这些语句，Logminer Standby不支持所有数据类型，可以在视图DBA_LOGSTDBY_UNSUPPORTED 中查看不支持的数据类型，如果使用了这种数据类型，则不能保证数据库完全一致。 Logical Standby数据库可以在恢复的同时进行读写操作。

 

Standby数据库的相关进程读取接收到的REDO数据（可能来自于Standby端的归档文件，也可能来自于Standby Redologs），再将其写入Standby数据库。保存之后数据又是怎么生成的呢？两种方式：物理Standby通过REDO应用，逻辑Standby通过SQL应用

 

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

一种是实时应用（Real-Time Apply）， 这种方式必须Standby Redo Log，每当日志被写入Standby Redo Log时，就会触发恢复，使用这种方式的好处在与可以减少数据库切换（Switchover 或者Failover）的时间，因为切换时间主要用在剩余日志的恢复上。

另一种是归档时应用，这种方式在Primary Database发生日志切换，触发Standby Database 归档操作，归档完成后触发恢复。 这也是默认的恢复方式。

 

如果是Physical Standby，可以使用下面命令启用Real-Time：

Alter database recover managed standby database using current logfile;

 

如果是Logical Standby，可以使用下面命令启用Real-Time：

Alter database start logical standby apply immediate;

 

查看是否使用Real-Time apply：

Select recovery_mode from v$archive_dest_status;

 

 

SQL> set wrap off
SQL> select process,status,thread#,sequence#,client_pid from v$managed_standby;

PROCESS STATUS THREAD# SEQUENCE# CLIENT_PID
--------- ------------ ---------- ---------- -----------------------------------

ARCH CONNECTED 0 0 240
ARCH CONNECTED 0 0 196
ARCH CONNECTED 0 0 1944
ARCH CONNECTED 0 0 3956
MRP0 WAIT_FOR_LOG 1 30843 N/A
RFS RECEIVING 1 30838 2620
RFS RECEIVING 1 30837 2612
RFS RECEIVING 1 30833 2652
RFS ATTACHED 1 30841 2628
RFS ATTACHED 1 30835 2604
RFS ATTACHED 1 30842 2608

已选择11行。

 

 

二． 数据保护模式

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

 

1. 最大保护（Maximum Protection）

这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的，它要求所有的事务在提交前其REDO不仅被写入到本地的Online Redologs，还要同时写入到Standby数据库的Standby Redologs，并确认REDO数据至少在一个Standby数据库中可用（如果有多个的话），然后才会在Primary数据库上提交。如果出现了什么故障导致Standby数据库不可用的话（比如网络中断），Primary数据库会被Shutdown，以防止数据丢失。

使用这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

 

2. 最高可用性（Maximum availability）

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

这种方式虽然会尽量避免数据丢失，但不能绝对保证数据完全一致。这种方式要求Standby Database 必须配置Standby Redo Log，而Primary Database必须使用LGWR，SYNC，AFFIRM 方式归档到Standby Database.

 

3. 最高性能（Maximum performance）

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

这种方式可以使用LGWR ASYNC 或者 ARCH 进程实现，Standby Database也不要求使用Standby Redo Log。

 

4. 修改数据保护模式步骤

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

2）修改模式：

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

如：SQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PROTECTION;

3) 打开数据库： alter database open;

4) 确认修改数据保护模式：

SQL>select protection_mode,protection_level from v$database;

 

 

 

三． 自动裂缝检测和解决

 

当Primary Database的某些日志没有成功发送到Standby Database， 这时候发生饿了归档裂缝（Archive Gap）。

缺失的这些日志就是裂缝（Gap）。 Data Guard能够自动检测，解决归档裂缝，不需要DBA的介入。这需要配置FAL_CLIENT， FAL_SERVER 这两个参数（FAL: Fetch Archive Log）。

从FAL 这个名字可以看出，这个过程是Standby Database主动发起的“取”日志的过程，Standby Database 就是FAL_CLIENT. 它是从FAL_SERVER中取这些Gap， 10g中，这个FAL_SERVER可以是Primary Database， 也可以是其他的Standby Database。

如：FAL_SERVER='PR1,ST1,ST2';

FAL_CLIENT和FAL_SERVER两个参数都是Oracle Net Name。 FAL_CLIENT 通过网络向FAL_SERVER发送请求，FAL_SERVER通过网络向FAL_CLIENT发送缺失的日志。 但是这两个连接不一定是一个连接。 因此FAL_CLIENT向FAL_SERVER发送请求时，会携带FAL_CLIENT参数值，用来告诉FAL_SERVER应该向哪里发送缺少的日志。 这个参数值也是一个Oracle Net Name，这个Name是在FAL_SERVER上定义的，用来指向FAL_CLIENT.

 

当然，除了自动地日志缺失解决，DBA 也可以手工解决。 具体操作步骤如下：

 

1） 查看是否有日志GAP：

SQL> SELECT UNIQUE THREAD#, MAX(SEQUENCE#) OVER(PARTITION BY THREAD#) LAST FROM V$ARCHIVED_LOG;

 

　　SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

　 2） 如果有，则拷贝过来

3） 手工的注册这些日志：

SQL> ALTER DATABASE REGISTER LOGFILE '路径';

 

 

 

 

四． 指定日志发送对象

 

1．VALID_FOR属性指定传输及接收对象

LOG_ARCHIVE_DEST_n参数中的VALID_FOR属性，用来指定传输的内容。从字面理解VALID_FOR就是基于那谁有效，该属性有两个参数值需要指定：REDO_LOG_TYPE和DATABASE_ROLE，我们基本上可以将其理解为：发送指定角色生成的指定类型的日志文件，该参数的主要目的是为了确保，一旦发生角色切换操作后数据库的正常运转。

其中，REDO_LOG_TYPE和DATABASE_ROLE两个参数可供选择的参数值如下：

REDO_LOG_TYPE：可设置为ONLINE_LOGFILE、STANDBY_LOGFILE、ALL_LOGFILES。

DATABASE_ROLE：可设置为PRIMARY_ROLE、STANDBY_ROLE、ALL_ROLES。

 

注意：VALID_FOR参数默认值是：VALID_FOR=（ALL_LOGFILES,ALL_ROLES）。

 

推荐手动设置该参数而不要使用默认值，在某些情况下默认的参数值不一定合适，如逻辑Standby在默认情况下就处于OPEN READ WRITE模式，不仅有REDO数据而且还包含多种日志文件（Online Redologs、Archived Redologs及Standby Redologs）。

默认情况下，逻辑Standby数据库生成的归档文件和接收到的归档文件在相同的路径下，这既不便于管理，也极有可能带来一些隐患。建议对每个LOG_ARCHIVE_DEST_n参数设置合适的VALID_FOR属性。本地生成的归档文件和接收到的归档文件最好分别保存于不同路径下。

 

2．通过DB_UNIQUE_NAME属性指定数据库

DB_UNIQUE_NAME属性是10g版本新增加的一个关键字，在之前版本并没有这一说法。该属性的作用是指定唯一的Oracle数据库名称，也正因有了DB_UNIQUE_NAME，REDO数据在传输过程中才能确认传输到DBA希望被传输到的数据库上。

当然要确保REDO数据被传输到指定服务器，除了在LOG_ARCHIVE_DEST_n参数中指定正确DB_UNIQUE_NAME属性之外，还有一个初始化参数LOG_ARCHIVE_CONFIG也需要进行正确的配置。该参数除了指定Data Guard环境中的唯一数据库名外，还包括几个属性，用来控制REDO数据的传输和接收：

SEND：允许数据库发送数据到远端。

RECEIVE：允许Standby接收来自其他数据库的数据。

NOSEND,NORECEIVE：自然就是禁止喽。

 

例如，设置Primary数据库不接收任何归档数据，可以做如下的设置：

LOG_ARCHIVE_CONFIG='NORECEIVE,DG_CONFIG= (PRI,ST) '

如果做了如上的设置，如果该服务器发生了角色切换，那它也没有接收REDO数据的能力。

 

 

 

 

五． Data Guard环境应配置的初始化参数

 

 

下列参数为Primary角色相关的初始化参数

DB_NAME

注意保持同一个Data Guard中所有数据库DB_NAME相同

例如：DB_NAME=Dave

DB_UNIQUE_NAME

为每一个数据库指定一个唯一的名称，该参数一经指定不会再发生变化，除非DBA主动修改它

例如：DB_UNIQUE_NAME=DavePre

LOG_ARCHIVE_CONFIG

该参数用来控制从远端数据库接收或发送REDO数据，通过DG_CONFIG属性罗列同一个Data Guard中所有DB_UNIQUE_NAME（含Primary数据库和Standby数据库），以逗号分隔，SEND/NOSEND属性控制是否可以发送，RECEIVE/NORECEIVE属性控制是否能够接收

例如：LOG_ARCHIVE_CONFIG='DG_CONFIG=(DavePre,DaveDG)'

LOG_ARCHIVE_DEST_n

归档文件的生成路径。该参数非常重要，并且属性和子参数也特别多(可以直接查询Oracle官方文档。Data Guard白皮书第14章专门介绍了该参数各属性及子参数的功能和设置)。例如：

LOG_ARCHIVE_DEST_1='LOCATION=l:/oracle/oradata/Dave VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=DavePre'

LOG_ARCHIVE_DEST_STATE_n

是否允许REDO传输服务传输REDO数据到指定的路径。该参数共拥有4个属性值，功能各不相同。

REMOTE_LOGIN_PASSWORDFILE

推荐设置参数值为EXCLUSIVE或者SHARED，注意保证相同Data Guard配置中所有DB服务器SYS密码相同

以下参数为与Standby角色相关的参数（建议在Primary数据库的初始化参数中也进行设置，这样即使发生角色切换，新的Standby也能直接正常运行）

FAL_SERVER

指定一个Net服务名，该参数值对应的数据库应为Primary角色。当本地数据库为Standby角色时，如果发现存在归档中断的情况，该参数用来指定获取中断的归档文件的服务器

例如：FAL_SERVER=DavePre

提示：FAL是Fetch Archived Log的缩写

FAL_SERVER参数支持多个参数值的哟，相互间以逗号分隔

FAL_CLIENT

又指定一个Net服务名，该参数对应数据库应为Standby角色。当本地数据库以Primary角色运行时，向参数值中指定的站点发送中断的归档文件

例如：FAL_CLIENT=DaveDG

FAL_CLIENT参数也支持多个参数值，相互间以逗号分隔。

DB_FILE_NAME_CONVERT

Standby数据库的数据文件路径与Primary数据库数据文件路径不一致时，可以通过设置DB_FILE_NAME_CONVERT参数的方式让其自动转换。该参数值应该成对出现，前面的值表示转换前的形式，后面的值表示转换后的形式

例如：DB_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

LOG_FILE_NAME_CONVERT

使用方式与上相同，只不过LOG_FILE_NAME_CONVERT专用来转换日志文件路径

例如：

LOG_FILE_NAME_CONVERT='f:/oradata/DavePre','l:/oradata/DaveDG'

STANDBY_FILE_MANAGEMENT

如果Primary数据库数据文件发生修改（如新建、重命名等）则按照本参数的设置在Standby数据库中作相应修改。设为AUTO表示自动管理。设为MANUAL表示需要手工管理

例如：STANDBY_FILE_MANAGEMENT=AUTO

 

 

对于归档失败的处理，LOG_ARCHIVE_DEST_n参数有几个属性，可以用来控制归档过程中出现故障时应该采取的措施。

1．REOPEN 指定时间后再次尝试归档

使用REOPEN=seconds（默认为300秒）属性，在指定时间重复尝试向归档目的地进行归档操作，如果该参数值设置为0，则一旦失败就不会再尝试重新连接并发送，直到下次REDO数据再被归档时会重新尝试。

例如，设置REOPEN为100秒：

LOG_ARCHIVE_DEST_2='SERVICE=DavePrimary LGWR ASYNC REOPEN=100'

2．ALTERNATE 指定替补的归档目的地

ALTERNATE属性定义一个替补的归档目的地，所谓替补就是一旦主归档目的地因各种原因无法使用，则临时向ALTERNATE属性中指定的路径写。

例如：

LOG_ARCHIVE_DEST_1='LOCATION=/disk1 ALTERNATE=LOG_ARCHIVE_DEST_2'

LOG_ARCHIVE_DEST_STATE_1=ENABLE

LOG_ARCHIVE_DEST_2='LOCATION=/disk2'

LOG_ARCHIVE_DEST_STATE_2=ALTERNATE

上述参数设置归档路径为/disk1，当/disk1路径下无法成功归档时，自动尝试向/disk2路径下归档文件。

从功能上来看，REOPEN与ALTERNATE是有一定重复的，不过需要注意一点，REOPEN属性比ALTERNATE属性的优先级要高，如果你指定REOPEN属性的值>0，则LGWR（或ARCn）进程会首先尝试向主归档目的地写入，直到达到最大重试次数，如果仍然写入失败，才会向ALTERNATE属性指定的路径写。

 

3．MAX_FAILURE 控制失败尝试次数

用REOPEN指定失败后重新尝试的时间周期，MAX_FAILURE则控制失败尝试的次数。

例如，设置LOG_ARCHIVE_DEST_1在本地归档文件时，如果遇到错误，则每隔100秒尝试一次，共尝试不超过3次，设置如下：

LOG_ARCHIVE_DEST_1='LOCATION=E:/ora10g/oradata/jsspdg/ REOPEN=100 MAX_FAILURE=3'

 

 

 

 注：摘自张晓明 《大话rac集群 高可用 备份 恢复》