Data Guard 3

3.1 Parameters for sending redo data

LOG_ARCHIVE_DEST_n指定本地归档和远程归档目的地

LOG_ARCHIVE_DEST_STATE_n指定是否开启归档地址，有三种值

Redo传输目的地由LOG_ARCHIVE_DEST_n设定，它的值的一个或多个字符串，下面简单介绍常用的相关值

SERVICE是redo destination的强制属性，必须在属性列表中第一个指定，它的值是Oracle Net服务名，用来连接到redo transport destination。The service name must be resolvable through an Oracle Net naming method to an Oracle Net connect descriptor that matches the Oracle Net listener(s) at the redo transport destination. 这个服务名必须能够通过Oracle Net命名方法解析成一个Oracle Net连接符，并且与目的地所监听的名字相匹配。而且connect descriptor必须指明对方使用的专有服务器，除非对方默认的就是专有。

SYNC指定采用同步的方式传输redo。在这种模式下，只有事务产生的redo条目被成功的传送到目的地，此事务才能提交。

ASYNC采用异步方式传输redo，此时事务不需要等待它自己所产生的redo被成功传输就能够提交。如果没有明确指定SYNC或ASYNC，则默认使用ASYNC。

NET_TIMEOUT属性用来指定在同步传输模式中，LGWR等待redo传输成功确认的时长，如果在NET_TIMEOUT指定的时间内，单位是秒，仍然没有收到确认消息，终止redo传输连接，记录错误。Oracle建议在同步传输模式下，使用NET_TIMEOUT属性，这样能够准确控制由于传输问题导致的延迟的最大时长。

AFFIRM指定，只有从redo source database接收来的redo被成功写到standby redo log后才向primary发送acknowledgement。

NOAFFIRM与AFFIRM正好相反，它不会等待写入standby redo log，而是直接发送acknowledgement。

DB_UNIQUE_NAME与DG_CONFIG。前者的值必须在DG_CONFIG中，并且它的值必须和redo destination中的DB_UNIQUE_NAME相匹配。如果不符合，则传输失败，记录错误。

VALID_FOR用来指定何时redo传输服务将redo传输到目的地，建议备库也指定此参数，这样在备库角色转换成主库后，能够正常传输redo。

REOPEN指明在redo传输失败与自动重连之间的最小秒数。

COMPRESSION是说是否压缩要传输的redo，这样在低带宽中会提升性能。但是，这东西不是免费的，它是Oracle Advanced Compression的一个特性，使用前需要购买license。

The following example uses all of the LOG_ARCHIVE_DEST_n attributes described in this section. A DB_UNIQUE_NAME has been specified for both destinations, as has the use of compression. If a redo transport fault occurs at either destination, redo transport will attempt to reconnect to that destination, but not more frequently than once every 60 seconds.

3.2 Configuring an Oracle Database to Receive Redo Data

这节描述如何配置redo transport destination接收并且归档从redo source database接收来的redo。

3.2.1 Creating and Managing a Standby Redo Log

这里讲讲standby redo log。在同步和异步redo传输模式中，要求redo destination有standby redo log，它用来存储从别的数据库接收来的redo，在结构上，standby redo log与redo log相同，创建方法也相同。RFS前台进程将接收来的redo写到standby redo log中。当redo source库切换日志，发送来的redo就会写到下一组standby redo，之前使用的standby redo就会被ARCn前台进程归档。

在redo source库上进行的filling和archiving过程，同样的在redo destination上进行着，相同的方式，用Oracle的话说就是 is mirrored。每个standby redo log至少要同redo log一样大，为了管理的方便，建议采用相同的大；每个standby redo log只要要比redo log file多一个，根据redo线程来定。在redo source库上查询V$LOG看看有多少个redo log，查询V$THREAD看看有多少个redo线程。

Oracle建议在主库上创建standby redo log，这样在进行switchover后能随时准备接受redo。

3.2.2 Cases Where Redo Is Written Directly To an Archived Redo Log File

当备库的standby redo log不可用，或者接收到的redo是用来解决redo gap时，备库会把接收到的redo直接写到归档redo中。这种情况下，redo会写到具体哪个位置呢？由LOCATION和LOG_ARCHIVE_DEST_n来决定，例如：

3.3 Cascaded Redo Transport Destinations

注意：这一特性需要在11g R2 11.2.0.2中使用，此版本之前会有一些问题。

A cascaded redo transport destination间接从备库接收主库的redo，而非直接从主库接收主库的redo。A standby database that cascades primary database redo to one or more cascaded destinations is known as a cascading standby database.将主库的redo级联到一个或多个级联目的地的备库称为cascading standby database。显然，cascading能够减轻由于主库传输redo的压力。

一个cascading standby database能够将主库的redo级联到最多30个cascaded destinations，它们可以是logical，physical或snapshot standby。

Primary database redo is written to the standby redo log as it is received at a cascading standby database. The redo is not immediately cascaded however. It is cascaded after the standby redo log file that it was written to has been archived locally. A cascaded destination will therefore always have a greater redo transport lag, with respect to the primary database, than the cascading standby database.

Cascading has the following restrictions:

A physical standby database is the only standby database type that can cascade redo；

The Data Guard broker does not support cascaded destinations

--当cascading standby database接收到redo后就会把主库的redo写到standby redo log中。但是，被写到standby redo里的redo不会被立刻cascade，只有当standby redo log被成功归档到本地后，才会开始cascade。因此，一个cascaded destination有很大的redo传输延迟。此外，cascading还有以下限制：

只有physical备库才能够cascade redo；

DG broker不支持cascaded destinations。

下面贴一个简单的例子

Oracle建议用来进行灾难恢复的备库应该直接接收主库的redo，这样能够提供最高级别的数据保护，而cascaded备库作为第二道防线，不过cascaded备库接收到的没有直接接收主库redo的cascading多。

3.4 Cascading Scenarios

3.4.1 Cascading to a physical standby

In this scenario, you have a mission-critical primary database. This database has stringent performance and data protection requirements, so you have decided to deploy a local physical standby database to provide zero data loss protection and a remote, cascaded physical standby database to protect against regional disasters at the primary and local standby database sites.

You can achieve the objectives described above by performing the following steps:

Create a physical standby database at a local site.

Create a physical standby database at a site that is sufficiently remote to provide protection against a regional disasters at the primary and local standby database sites.

Configure the local standby database as a SYNC redo transport destination of the primary database.

Configure the remote physical standby database as a cascaded destination of the local standby database.

3.4.2 Cascading to Multiple Physical Standbys

In this scenario, you have a primary database in North America and you wish to deploy three replicas of this database in Europe to support read-only reporting applications. For cost and performance reasons, you do not wish to maintain network links from North America to each of your European sites.

You can achieve the objectives described above by performing the following steps:

Create a network link between your North American site and one of your European sites.

Create a physical standby database at each of your European sites.

Open your physical standby databases in real-time query mode.

Configure the physical standby database at the European endpoint of your transatlantic network link to cascade redo to your other European standby databases.

Configure the physical standby database at the European endpoint of your transatlantic network link as a cascaded destination of your primary database.

3.5 Preparing for a Role Transition

1.查询主库上的V$ARCHIVE_DEST_STATUS，检查是否存在redo传输错误或者redo断层，比如要查询LOG_ARCHIVE_DEST_2的备库状态，那么执行：

SQL> SELECT STATUS,GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;

STATUS GAP_STATUS

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

VALID NO GAP

2.确保备库上的临时文件与主库的临时文件相匹配

3.把即将变成主库的备库上的所有延迟redo应用移出

4.在把一个RAC的主库变成备库之前，停掉所有的主库，只留下一个，待switchover完成后，所有的主库实例就可以启动了

5.把实时查询模式的备库进行switchover，要把备库所有的实例切换到mount状态，这样能够更快的完成角色转换，并且结束所有连接到物理备库的会话。

3.5.1 Role Transitions

Switchover是在有计划的停用时，减少主库宕机时间，比如OS或者硬件升级，或者数据库软件的滚动升级，打补丁之类的。Switchover分为两个阶段，第一阶段，主库变身为standby，第二阶段，备库变身primary。