DG（Data Guard，数据卫士）不是一个备份恢复的工具，然而，DG却拥有备份的功能，在物理DG下它可以和主库一模一样，但是它存在的目的并不仅仅是为了备份恢复数据，应该说它的存在是为了确保企业数据的高可用性，数据保护以及灾难恢复。DBA可以通过将一些操作（例如查询报表）转移到备库执行的方式来减小主库的压力，构建高可用的企业数据库应用环境。
在DG环境中，至少有两个数据库，一个处于OPEN状态对外提供服务，这个数据库叫作主库（Primary Database）。第二个处于恢复状态，叫作备库（Standby Database）。在通常情况下，主库对外提供服务，用户在主库上进行操作，操作被记录在联机日志和归档日志中，这些日志通过网络传递给备库，然后在备库上被应用，从而实现主库和备库的数据同步。Oracle对这一过程进一步地优化设计，使得日志的传递、恢复工作更加自动化、智能化，并且提供一系列参数和命令简化了DBA工作。如果软硬件升级，那么可以把备库切换为主库继续对外服务，这样既减少了服务停止时间，并且数据不会丢失。如果异常原因导致主库不可用，那么也可以把备库强制切换为主库继续对外服务，这时数据损失都和配置的数据保护级别有关系。所以，Primary和Standby只是一个角色概念，并不固定在某个数据库中。
每个技术都有其优缺点，下面来看看DG有哪些优缺点。
DG的优点主要有以下几点内容：
① 灾难恢复及高可用性。
② 全面的数据保护。
③ 有效利用系统资源。
④ 在高可用及高性能之间更加灵活的平衡机制。
⑤ 故障自动检查及解决方案。
⑥ 集中的、易用的管理模式。
⑦ 自动化的角色转换。
DG的缺点主要有以下几点内容：
① 由于传输整个日志文件，所以，需要较高的网络传输带宽。
② 在Oracle 11g之前的物理备库虽然可以以只读方式打开，然后执行查询、报表等操作，但需要停止应用日志，这将使目标库与源数据不能保持同步，如果在此期间源数据库发生故障，那么将延长切换的时间。从Oracle 11g开始，ADG可以在数据库打开的情况下应用日志，这极大地提高了DG的应用范围。
③ 逻辑备库不能支持某些特定的数据对象和数据类型。
④ 不支持双向复制，所以，无法应用于信息集成的场合。
⑤ 只能复制整个数据库，不能选择某个SCHEMA或表空间或表进行单独复制。
⑥ 不支持异构的系统环境，需要相同的操作系统版本和数据库版本（Oracle 11g支持部分异构平台）。
将日志文件从 原数据库 传输到 目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用方案。
DG整个过程分成3部分：
日志发送（Redo Send）
日志接收（Redo Receive）
日志应用（Redo Apply）
两种日志传送方式：
主库 primary database 在运行过程中，会不断产生redo重做日志，这些日志需要发送到备库 standby database，这个发送动作可以由
主库的两种日志传输方式 来完成：
ARCH进程
LGWR进程
ARCH进程，可以理解为 传归档日志
LGWR进程，可以理解为 传重做日志
主库产生了日志以后，通过 LGWR进程 写入在线重做日志
重做日志满足一定的条件，会切换
如果开了归档，重做日志就会归档，通过ARC0归档进程(编号有累加）将该日志归档
另外一个归档进程 通过网络 将归档日志传输到备库
备库上的【RFS】负责接收日志
接收以后，有两种情况：–【接收以后的动作】参考这里
1.如果备库配置了Standby RedoLogs，会将传输过来的日志复制到这里
然后将备用日志归档到本地的归档目录里去，再应用归档
2.如果备库没有配置Standby RedoLogs，RFS接收到日志后
会直接放到本地的归档目录，然后再应用日志 --奇怪，还是要放到归档目录
应用日志也有两种：
物理的叫MRP进程
逻辑的叫LSP进程
dg就是这两个进程,ARCH和LGWR，搞清楚了就好了
一个是归档进程
一个是重做日志
不同的日志应用方式的详解：
主库：
产生日志后通过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重做日志 归档后 再应用
同步的弊端：
同步的方式，传输到备库后，需要等待回复，如果因为网络问题一直等待回复，会卡死，把主库挂死（所以感觉同步还是有很大的风险的），会影响生产，数据是一致的，但是生产挂了。
最大保护：可以保证主库、备库同步，任何情况下主库的损毁都不会导致已提交的数据丢失。如果主库和备库之间的网络出现问题，或者备库本身出现问题，都会导致主库停止数据处理
最大可用：保证主库和备库的同步，与上面的区别是当网络或备库不可用时，主库仍可以继续。该保护模式下，零数据丢失
最大性能：缺省模式，主库、备库是异步的，这种模式可能在主库出现损毁时，丢失一部分数据。但是这种模式对主库的负荷最小，因此具有最好的性能。
主从切换：
switchover:无损的
failover:破坏性的操作
当主库的某些日志没有成功发送到备库，这时候发生了归档裂缝（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 传输到 灾备数据库