网络上和官方文档配置Data Guard 的步骤已经非常成熟，个人觉得应该逐渐深入，去理解其原理，挖掘其精髓

这篇文章是个人学习总结的笔记，如果写的有错的地方，还望大家留言指正

下图为一个ADG的模型，那么这篇文章就来研究图中的箭头的原理，也就是日志是如何发送的

图中，主库在运行时会不断产生redo log，这些日志会通过网络传送到备库，这个传送动作，可以由ARCH完成，也可以由LGWR完成，选用哪种进程，对数据库的可用性和DG的保护能力有着很大的区别。

1.使用ARCH进程传送日志

主库不断的产生redo log，这些日志被LGWR写进联机日志，当一组联机日志被写满，会发生日志切换，并且ARCH会将其归档，本地归档是LOG_ARCHIVE_DEST_1='LOCATION=/...'这种参数定义，ARCH进程还会通过网络把归档日志传送给备库的一个叫做RFS的进程，备库接受日志并写入到归档日志，然后备库的MRP进程（redo apply）或者LSP进程（SQL apply）在备库上应用这些日志，于是数据就同步了。

使用ARCH传递的问题也是很明显的，只有日志切换作为前提，才能传送日志，如果主库异常停机，联机日志丢失，导致无法归档，那么丢失数据是在所难免！

在默认情况下，主库就是用ARCH进程传送日志，不需要特别的设置。

2.使用LGWR进程传送日志

LGWR又分为SYNC（同步）和ASYNC（异步）两种方式

2.1LGWR进程的SYNC方式

主库产生redo log要同时写入到日志文件和网络，即LGWR把日志写到本地联机日志文件的同时，还发送给本地的LNSN进程（Network Server Process），然后LNSN进程把日志内容通过网络发送到备库。

LGWR必须等待写入本地联机日志和LNSN进程传送成功，主库的事物才能提交，这就是实时同步的原理。

备库的RFS进程把接收到的日志立刻写入standby redo log中，所以在备库上看，最后一个日志总是IN-MEMORY,这也是我当初疑惑的一个问题，现在终于清晰！

备库的恢复方式可以是实时恢复，也可以是完成对standby redo log的归档后恢复。

另外NET_TIMEOUT参数单位为秒，作用是该段时间网络无响应，LGWR会抛出错误

LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30'

2.2使用LGWR进程的ASYNC方式

使用LGWR SYNC方式也有弱点，如果在发送给standby db过程中出错，LGWR会报错，主库事物无法完成，

主库LGWR过分依赖网络状态，如果网络不能保证365天高速无悬念和不会被挖掘机挖断光纤，或者对数据同步不苛刻，也可以采用LGWR ASYNC方式。

主库产生redo log之后，LGWR-->LNSN，但是LGWR只需要成功写入日志文件，事物即可允许提交，不必等待LNSN进程传送成功。

主库联机日志写满后，归档，也会触发备库的standby redo log归档，然后触发MRP活LSP进程恢复归档。

即备库的恢复方式，只能是完成对standby redo log的归档后恢复。

由于LSWR不会等待LNSN，所以无需配置NET_TIMEOUT参数。

--------------------------------------分割线 --------------------------------------

--------------------------------------分割线 --------------------------------------