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需要用到的参数，说起来挺简单的，那具体的实施过程以我们测试环境搭建的一套环境作为实例进行说明