DataGuard运行原理非常简单：传输日志、应用日志。下图表示了DG的基本架构
日志传输服务将主库产生的日志数据传到从库。
应用服务（Apply Service）验证日志数据，并且更新从库的数据文件。
主数据库的写进程更新数据文件，并不依赖于DataGuard架构。
当网络或者从库故障恢复时，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
用户commit一个事务，将在Redo Buffer中生成一些redo record 。LGWR从Log buffer中读取redo record并将其写入Online Redo Logs,于此同时等待LNS进程的确认。
LNS从Redo Buffer中读取相同的redo record，通过ONS将其传输到从库。RFS接收日志，将其写入Standby Redo Logs。
当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进程负责传输到从数据库。
