DataGuard运行原理非常简单：传输日志、应用日志。下图表示了DG的基本架构

1. 日志传输服务将主库产生的日志数据传到从库。

2. 应用服务（Apply Service）验证日志数据，并且更新从库的数据文件。

3. 主数据库的写进程更新数据文件，并不依赖于DataGuard架构。

4. 当网络或者从库故障恢复时，DG自动重传已经被主库归档的日志数据。

• 日志传输服务Redo Transport Services

         Redo Transport Services协调主从库之间的日志传输。当主库LGWR写日志时，Log Network Server (LNS)程序从Log buffer cache中读取日志数据，通过Oracle Net Services将数据传输到从库上。从库上的Remote File Server (RFS)接收传过来的日志。RFS将接收到的日志写到standby redo log file (SRL).在多从库环境下，主库为每个从库都启用一个独立的LNS进程，用来传输日志数据。

         使用LNS进程，DataGuard支持两种日志传输方式：同步、异步。

         同步日志传输Synchronous Redo Transport

         Synchronous transport (SYNC) 也被称为"零数据丢失"。只有当LNS确认日志被传输到从库并且已经写入磁盘后，主库上的commit操作才会被认为成功。

Data Guard 日志传输进程架构

SYNC redo transport architecture

1. 用户commit一个事务，将在Redo Buffer中生成一些redo record 。LGWR从Log buffer中读取redo record并将其写入Online Redo Logs,于此同时等待LNS进程的确认。

2.  LNS从Redo Buffer中读取相同的redo record，通过ONS将其传输到从库。RFS接收日志，将其写入Standby Redo Logs。

3. 当RFS写日志成功后，传输一个确认信号给主库上的LNS，LNS将此确认信息告知LGWR。此时LGWR才能反馈给用户提交成功的信息。 

Asynchronous transport (ASYNC)

  日志异步传输，LGWR无需等待LNS的确认信息。这种情况，standby几乎对主库没有任何的性能影响。如果LNS传输日志的速度跟不上LGWR写，当Log buffer被回收后，LNS就从online redo file从读取日志传输到从库。一旦LNS的速度跟上了，又会从Log buffer中读取数据。

  有一种情况，假设LNS正在读的current log的编号为10，再读的过程中发生了两次日志切换。现在current log编号变成了12. 这个时候LNS读完了10. 它不会接着去读取11号日志。而是直接切换到当前日志，编号为12的。 这种情况，11号日志没有被LNS传到standby 数据库. 我们称之为log file gap

当发生log file gap时，被归档的日志文件由arch进程负责传输到从数据库。