DATA GUARD(笔记加转载加理解--未完，整理中

DATA GUARD的最主要的功能

1 冗灾冗余

2 性能提升，读写分离

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

1、 日志发送（Redo Send）

2、 日志接收（Redo Receive）

3、 日志应用（Redo Apply）

1 日志发送（Redo Send），一共有2种方式来实现。

1.1 ARCH进程发送

1.1.1 Primary Database 不断产生Redo Log，这些日志被LGWR 进程写到联机日志（onlineredolog)

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

从DB从非归档模式切换到归档模式，需要手工指定这个参数的。

（修改本地归档位置 alter
system set log_archive_dest_1 = 'LOCATION=/u01/arch' scope=both;）

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

默认有3组，每组1个文件默认大小50M

非归档模式下，切换会覆盖原先数据

归档模式下，覆盖原先数据必须保证ARCH进程写到归档日志，为以后DB恢复提供依据

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

这个进程用于接受归档日志的。

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

ARCH进程来实现

1.1.6 Standby Database 端的MRP(Managed Recovery Process)进程（Redo Apply）-----物理Standby
块级别的恢复，直接修改数据块级别数据来实现

或者LSP （Logical Standby Process）进程（SQL Apply）-----逻辑Standby，还原成SQL语句，通过DB引擎来执行SQL语句，是通过执行SQL语句来实现

在Standby Database上应用这些日志，进而同步数据。

几点说明：
（1）用ARCH模式传输日志不写Standby Redologs，直接在Standby上保存成归档文件
（2）逻辑Standby接收后将其转换成SQL语句，在Standby数据库上执行SQL语句实现同步，这种方式叫SQL Apply。
（3）物理Standby接收完Primary数据库生成的REDO数据后，以介质恢复的方式实现同步，这种方式也叫Redo Apply。
（4）使用ARCH进程的问题在于： Primary Database 只有在发生归档时才会发送日志到Standby Database。
如果Primary Database 异常宕机，联机日志中的Redo 内容就会丢失，因此使用ARCH 进程就可能会有数据丢失的问题，避免这种情况可以使用LGWR
或者把这些onlineredo直接拷贝到备库，通过手工的恢复实现。

在缺省方式下，Primary Database使用的是ARCH进程，参数设置如下：
alter system set log_archive_dest_2 = 'SERVICE=ST' scope=both;

1.2 使用LGWR进程，分SYNC（同步）和ASYNC（异步）
1.2.1 使用LGWR 进程的SYNC 方式
1.2.1.1 Primary Database 产生的Redo 日志要同时写入日志文件和网络。
即LGWR进程把日志写到本地日志文件的同时还要发送给本地的LNSn进程（Network Server Process），
再由LNSn（Log Network Server process）进程把日志通过网络发送给远程的目的地，
每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
1.2.1.2 LGWR 必须等待写入本地日志文件操作和通过LNSn进程的网络传送都成功，Primary Database 上的事务才能提交，这就是SYNC的意义。
（个人理解，网络的性能很大程度上会影响本地DB性能，是牺牲系能提高安全性。）

1.2.1.3 Standby Database的RFS进程把接收到的日志写入到Standby Redo Log日志中。
1.2.1.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 ，LSP就会立即进行恢复；
归档恢复： 在完成对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.2.2 使用LGWR ASYNC
使用LGWR SYNC方法的可能问题在于，如果日志发送给Standby Database过程失败，LGWR进程就会报错。也就是说Primary Database的LGWR 进程依赖于网络状况，有时这种要求可能过于苛刻，这时就可以使用LGWR ASYNC方式。 它的工作机制如下：
1.2.2.1 Primary Database 产生Redo 日志后，LGWR 把日志同时提交给日志文件和本地LNS 进程，但是LGWR进程只需成功写入日志文件就可以，不必等待LNSn进程的网络传送成功。
1.2.2.2 LNSn进程异步地把日志内容发送到Standby Database。多个LNSn进程可以并发发送
1.2.2.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;