1.关于Data Guard日志接收的总结：
备库的RFS进程接收到日志后，就把日志写到standby redo log或者archived log file文件中。
而归档日志会被放在什么位置取决于standby database归档路径的选择，
如果配置了standby_archive_dest,则使用这个参数指定的目录；
如果配置了log_archive_dest_n，该参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)，则使用这个参数指定的目录；
如果数据库的COMPATIBLE参数大于等于10，则选取任意一个LOG_ARCHIVE_DEST_n的值；
如果standby_archive_dest和log_archive_dest_n参数都没有配置，使用缺省的standby_archive_dest参数，这个缺省值是$Oracle_HOME/dbs/arch。
2.关于Data Guard日志应用的总结：
日志应用服务，就是在备库上重演主库的日志，从而实现两个数据库的数据同步。
根据备库重演日志的方式不同，可分为物理和逻辑两种类型。
物理使用的media recovery技术，在数据块级别进行恢复。这种方式没有数据类型的限制，可以保证两个数据库完全一致。
而逻辑使用的logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句。
根据redo apply发生的时间可以分为2种：
一种是实时应用，这种方式必须有standby redo log，每当日志被写入standby redo log时，就会触发恢复，
使用这种方式的好处就在于可以减少数据库切换的时间，因为切换时间主要用在剩余日志的内容恢复上。
另一种是归档时应用，这种方式在主库发生日志切换之后，才触发备库的归档，归档完成后再触发恢复，这也是默认的方式。
如果是物理备库，可以使用下面命令启用real-time
alter database recover managed standby database using current logfile;
如果是逻辑备库，可以使用下面命令启用real-time
alter database start logical standby apply immediate;
查看是否使用了real-time
select recovery_mode from v$archive_dest_status;
3.关于Data Guard环境中的重要进程的总结：
主库：
LGWR：在主库上，这个进程负责吧redo buffer中的内容写入online redo log。
LNS（logwriter network service）：LNS进程读取日志，并通过网络发送给备库，这个进程的目的是为了给LGWR减轻负担，LGWR进程不用再参与到网络日志的传送中。
ARCH：归档进程，在主库中可有30个归档进程，其中有一个是专门负责本地归档的，不参与Gap Resolution,
而其他的arch进程都可以进行Gap Resolution。
备库
RFS（remote file server）：这个进程负责接收网络上传来的redo日志，并把这些日志写到standby redo log文件中。
ARCH：同样是归档进程，只是在备库上，需要归档的是standby redo log文件的内容。
MRP（magaged recovery process）：这个进程负责协调介质恢复管理工作，整个物理备库就是建立在介质恢复技术上的。
PR0x（Parallel Recover Process）：这是进行具体恢复工作的进程，如果是real-time apply模式下，这些进程会从standby redo log文件中读日志；而在其他模式下，是从归档日志中读取日志然后再进行日志应用。
LSP（logical standby process）：这个进程在logical standby中才有，功能和物理备库的MRP进程类似，负责协调SQL APPLY过程。