DG ARCH进程 详解：
主库：
产生日志后通过LGWR进程写入在线重做日志，当满足相关条件后在线重做日志会进行切换，ARC0进程归档该日志至主库本地的归档目录，归档完成后，ARC1进程就会将归档日志传输到备库
备库：
RFS进程负责接收日志
1）如果备库有Standby重做日志，则把日志复制到Standby重做日志，接着把Standby重做日志归档至备库本地归档目录，最后应用归档
2）如果没有配置Standby重做日志，RFS进行接收日志后，直接把它放到备库的归档目录下，再应用该日志
使用 ARCH 进程存在的问题：
主库 只有在发生归档时 才会发送日志到备库
如果主库异常宕机，联机日志中的redo内容就会丢失，因此使用ARCH进程 无法避免数据丢失 的问题，要想避免数据丢失，就必须使用LGWR，而使用LGWR又分为 同步和异步 两种方式
12c增加了 fast sync模式
LGWR ASYNC --异步过程详解
主库：
产生日志，只要有新的重做日志产生，LGWR进程就触发LNSn进程把新生成的重做日志传输到备库
ASYNC是 redo buffer 保存到 online redo log 后，LNSn才开始传输
备库：
RFS进程负责接收日志，接收日志后将其写入Standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等Standby重做日志 归档后 再应用
LGWR-SYNC --同步过程详解
主库：产生日志，只要有新的重做日志产生，LGWR进程就将触发 LNSn进程 把新生成的重做日志传输到备库
SYNC是在 redo buffer 时，LNSn进程就开始传输
备库：RFS进程负责接收日志，接收到日志后将其写入Standby重做日志，如果备库开启了实时应用，就立即做日志应用，如果没有开启，则等Standby重做日志 归档后 再应用
同步的弊端：
DG三种数据保护模式：
最大保护：可以保证主库、备库同步，任何情况下主库的损毁都不会导致已提交的数据丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库停止数据处理
最大可用：保证主库和备库的同步，与上面的区别是当网络或备库不可用时，主库仍可以继续。该保护模式下，零数据丢失
最大性能：缺省模式，主库、备库是异步的，这种模式可能在主库出现损毁时，丢失一部分数据。但是这种模式对主库的负荷最小，因此具有最好的性能。
主从切换：
switchover:无损的
failover:破坏性的操作
DG 归档裂缝 检测和解决
当主库的某些日志没有成功发送到备库，这时候发生了归档裂缝（archive gap），缺失的这些日志就是裂缝
dg能够自动检测，解决归档裂缝，不需要DBA介入
这需要配置 FAL_CLIENT,FAL_SERVER 这两个参数
FAL_CLIENT 通过网络向 FAL_SERVER 发送请求
FAL_SERVER 通过网络向FAL_CLIENT 发送缺失的日志
除了自动解决，DBA也可以手工解决
12c Far Sync 两地三中心：
12c后，在主备之间放一个远程同步实例，可以放在距离主库较近的异地，专门接收日志
通过 sync 的方式把 redo传输到 far sync 实例，然后通过 async的方式 传输到终端灾备数据库
在此过程中，如果 far sync 实例 出现问题，生产数据库可以直接通过 async 方式把 redo 传输到 灾备数据库
