原文地址：https://www.cnblogs.com/SharkXu/archive/2013/11/19/REDO_TRANSPORT.html
Dataguard中日志传输服务
之前，原本已经尝试过配置oracle实例的逻辑和物理standby结构，并且做个一些role交换操作，可是由于昨天学习rman的部分命令时没留意，误删掉了primary DB上的所有归档日志，因为原来是在maximum protection模式下，standby DB上还存在archivel gap，结果之前搭建的standby实验环境彻底挂了，primary DB也自动停了。我只好把primary DB在nomount模式下改为maximum performance模式，并将控制standby redo log传输的log_archive_dest_state_n设置为defer，才把primary DB启动起来。现在，除了重建standby，还没找到其他的弥补方法，看来对data guard的理解还是停留在照猫画虎的操作上，根本米有理解它的原理啊。所以重新来过，从基础开始好了。
首先，data guard的主要原理主要是primary DB将所有操作产生的redo log 传输到standby DB上，在由standby DB对此进行应用的。从而产生一个一致的standby DB。在data guard中，存在两类SYNC和ASYNC，下面分别描述两类的工作方法，从而进一步认识它的原理。
下图是SYNC模式的流程图。 1、当user 发出 commit命令后，将产生一条 redo record （也称作redo entry）放入SGA中的 redo buffer 中，后台进程LGWR将读取此redo record，将其写入online redo log file。并等待从LNS进程传来的确认信息。 2、LNS（Log Network Server） 进程同样从redo log buffer读取redo record，并将其通过Oracle Net Services传输给standby DB。在standby DB上的RFS后台进程将接收到的redo record写入standby database中。 3、当RFS确定写入所有的redo record到磁盘后，向primary DB的LNS发送确认信息。当LGWR收到LNS转发的确认信息后，才返回commit成功的消息给user。
接下来来看ASYNC：类似于SYNC，只是primary DB上的LGWR可以不必等待LNS的确认信息，而且LNS可以读取online redo log中的redo record。对于ASYNC，就可以考虑使用压缩方式传输redo record，从而节省带宽，但是这会使CPU的利用升高。此外，如果LNS在读取online redo log中记录时刚好遇到online switch，则可能造成standby的archivelog gap。LNS的不同步记录，在提高性能的同时也可能会产生数据的丢失。
对于redo log的gap的处理，oracle的data guard有自己的自动处理方法。log file gap主要出现在primary DB上不断有事务被提交，同时，LNS可能由于网络或是standby DB的问题，不能及时同步造成的。此时，primary DB会继续运行，循环使用redo logs，并进行归档。Data Guard会在primary DB上使用一个ARCH进程不断的ping standby DB。当与standby DB可以进行通信时，ARCH的ping进程会通过RFS查询standby的控制文件，获得上一次完成log同步的SCN从而确定从哪一个归档log开始进行同步，从而填补gap。当完成这一步，会自动过度到从当前的日志文件中同步。具体的流程图如下：
对于物理standby来说，它应用接受到的redo record是按下图的方式的：
redo apply维持一个standby database是通过精确的物理块来进行primary DB的备份的。RFS进程从primary DB接收到redo record，并将其写入standby redo log（后面将被简称为SRL）。redo apply通过介质恢复，将SRL中的redo record读入内存中，介质恢复协调器（MRP0）管理恢复session，iang具有相同SCN的redo进行合并（这多是在RAC环境中），并分析redo映射到不同的 apply 进程。不同的 apply 进程读取映射的数据块，并将其写入相应改变的数据块。redo apply 会自动设置与cpu数目相等的 apply 进程。
对于使用 sql apply 的逻辑standby，其具体使用 redo 如下图
SQL apply使用的是逻辑 standby 进程进行协调应用相应的redo log中的改变。sql apply进程读取SRL，并将其转化为逻辑的记录改变，并建立SQL事务，并应用这些SQL到standby DB上。显然相对于redo apply，sql apply 更耗费cpu、io和内存等资源。