一、名词：
RFS（remote file server）：这个进程负责接收网络上传来的redo日志，并把这些日志写到standby redo log文件中。
ARCH：同样是归档进程，只是在备库上，需要归档的是standby redo log文件的内容。
MRP（magaged recovery process）：这个进程负责协调介质恢复管理工作，整个物理备库就是建立在介质恢复技术上的。
LSP（logical standby process）：这个进程在logical standby中才有，功能和物理备库的MRP进程类似，负责协调SQL APPLY过程。
standby redo log（SRL）：Data Guard在备库中，建议配置一种额外的日志文件。叫做standby redo log（SRL），和传统的online redo log（ORL）相比，SRL有着特殊的要求和作用。
online redo log（ORL）：
fetch archive log(FAL) :
FAL_SERVER :指定一个Oracle Net service name,standby数据库使用这个参数连接到FAL server,这个参数适用于standby站点。比如,FAL_SERVER = PrimaryDB,此处PrimaryDB是一个TNS name,指向primary库。
FAL_CLIENT:指定一个FAL客户端的名字，以便FAL Server可以引用standby库，这也是一个TNS name，primary库必须适当配置此TNS name指向stanby库。这个参数也是在standby库端设置。比如，FAL_CLIENT = StandbyDB,StandbyDB是standby库的TNS name。
GAP:当备库不能接受到一个或多个主库的归档日志文件时候，就发生了archive gap。丢失的归档日志文件就是gap，如果有gap，如果发生gap，dg会自动检测和处理通过拷贝丢失的日志到备库。
二、架构
- standby redo log（SRL）：
-〉Data Guard在备库中，建议配置一种额外的日志文件，叫做standby redo log（SRL），和传统的online redo log（ORL）相比，SRL有着特殊的要求和作用。两者的关系可以从下面的几点来对比：
（1）.SRL和ORL两种文件是完全相同的，只是两者发挥的作用和场景不同。
（2）.SRL只在备库上起作用，（虽然主库也可以配置SRL），但是当数据库处于主库角色的时候，SRL是不活动的，只有经过了角色切换，变成了备库角色时，SRL日志才会变成活动的。
（3）.对于处于备库角色的数据库来说，ORL不是必须的，也不会起作用，（在很多时候，备库虽然显示有ORL，但是并没有真正的操作系统文件存在，只有当角色切换，变成主库角色时，才真正在操作系统上创建ORL文件）！
（4）.对于处于备库角色的数据库来说，他从主库接收到的日志可以记录在SRL文件中，也可以记录在归档日志文件中，具体写在哪个文件中取决于具体配置，但是不会写在ORL中。
（5）.SRL必须和ORL大小完全一致，否则SRL也不会被用到。其次，从数量上，应该按照每个实例或日志线程N+1的数量关系来配置，例如2个实例的RAC，如果每个实例3组日志，则SRL应该是（3+1）*2=8组。
-〉 是否使用SRL，关键区别在于RFS把接收到的日志，是写在归档日志里，还是写在SRL里。
使用SRL可以带来2大好处：
（1).性能
如果不使用SRL，则备库的RFS会把接收到的日志记录到归档日志文件中，每当主库做日志切换时，才会触发备库对当前归档日志的归档操作，因此他必须等待备库的RFS进程创建并且初始化下一个归档日志文件，用来容纳以后传递的REDO内容。因此这个过程会影响主库日志的切换进度，当然对于异步传送来说不影响主库性能，但是仍然会导致备库日志落后的情况。
然而使用了SRL，因为SRL预先建好，因此日志切换时，无需额外的文件初始化工作，因此性能要更好一些。
（2）.支持Real-Time Apply（RTA）
前面介绍了实时同步，备库最后一个日志总是IN-MEMORY状态。 - FAL_CLIENT和FAL_SERVER
FAL_CLIENT和FAL_SERVER是配置dataguard用到的两个参数,FAL指获取归档日志(Fetch Archived Log)
在一定的条件下，或者因为网络失败，或者因为资源紧张，会在primary和standby之间产生裂隙，也就是有些归档日志没有及时的传输并应用到standby库。因为MRP(managed recovery process)/LSP(logical standby process)没有与primary直接通讯的能力来获取丢失的归档日志。因此这些gaps通过FAL客户和服务器来解决，由初始化参数定义FAL_CLIENT和FAL_SERVER。
FAL_SERVER指定一个Oracle Net service name,standby数据库使用这个参数连接到FAL server,这个参数适用于standby站点。比如,FAL_SERVER = PrimaryDB,此处PrimaryDB是一个TNS name,指向primary库。
FAL_CLIENT指定一个FAL客户端的名字，以便FAL Server可以引用standby库，这也是一个TNS name，primary库必须适当配置此TNS name指向stanby库。这个参数也是在standby库端设置。比如，FAL_CLIENT = StandbyDB,StandbyDB是standby库的TNS name。
FAL_CLIENT和FAL_SERVER应该成对设置或改变。
这两个参数只需在standby库设置，但也可以在primary库设置这两个参数，以方便switchover或failover时primary库转变为standby角色。 - gap及处理
当备库不能接受到一个或多个主库的归档日志文件时候，就发生了archive gap。丢失的归档日志文件就是gap，如果有gap，如果发生gap，dg会自动检测和处理通过拷贝丢失的日志到备库。
(1).gap什么时候被发现
当主库在本地归档一个日志，但是备库没有收到，每分钟，主库就会看下他的备库是否在规定日志文件序号上有gap。
(2).gap怎么被解决
gap 恢复通过投票机制处理，对物理和逻辑备库，dg检查gap及通过在主库上面获取丢失的redo日志文件来解决。
自动gap恢复依赖主库的可用性，如果主库不可样，你配置了多个物理备库，那么你可以配置额外的参数，这样redo apply就可以在别的备库上来解决gap。
三、模式
数据保护模式是指备库和主库之间数据同步程度。
Data Guard允许定义3种数据库保护模式，分别是最大保护、最大可用、最大性能模式。
这3种模式的区别在于，当主库发生故障时，备库的数据会和主库有多大的差距。
来源：CSDN
作者：大慧说
链接：https://blog.csdn.net/nirvana52/article/details/104670834