dg知识点

一、名词：

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会自动检测和处理通过拷贝丢失的日志到备库。
MRP：managed recovery process，简单来说就是物理standby是通过这个进程来实现数据的同步的，直接通过standby redo log或者是归档日志（取决于模式不同）来进行的一个数据恢复。
LSP:logical standby process：逻辑standby的方式，和上面的一样，只不过当中多了一步将redo信息转换成sql语句再恢复。也可以从这里看出逻辑standby和物理standby的不同。
二、架构

1.db_name和db_uniquename
数据库名，其实这么说有点不准确，很容易让人理解错误，o小白干脆就把他理解成dg名算了，方正整个dg中所有的DB_NAME都必须是一致的;
DB_UNIQUE_NAME：真正的数据库名，用来标识在dg中不同的数据库的名字，以示区分。
2.DB_FILE_NAME_CONVERT/LOG_FILE_NAME_CONVERT：
如果standby数据库和primary数据库在同一个系统中或者standby系统的数据文件或者是日志文件位置和primary库的不一样，那这个参数必须在standby库的参数文件中进行配置，以逗号分隔，将文件的路径用单引号括起来，以先primary库后standby库的方式配置。例如：db_file_name_convert=’/u01/app/oracle/oradata/××××/datafile/’,’/u01/app/oracle/oradata/×××××/datafile/’。
3. 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状态。
4. 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角色。
5. gap及处理
当备库不能接受到一个或多个主库的归档日志文件时候，就发生了archive gap。丢失的归档日志文件就是gap，如果有gap，如果发生gap，dg会自动检测和处理通过拷贝丢失的日志到备库。
(1).gap什么时候被发现
当主库在本地归档一个日志，但是备库没有收到，每分钟，主库就会看下他的备库是否在规定日志文件序号上有gap。
(2).gap怎么被解决
gap 恢复通过投票机制处理，对物理和逻辑备库，dg检查gap及通过在主库上面获取丢失的redo日志文件来解决。
自动gap恢复依赖主库的可用性，如果主库不可样，你配置了多个物理备库，那么你可以配置额外的参数，这样redo apply就可以在别的备库上来解决gap。

三、模式

数据保护模式是指备库和主库之间数据同步程度。
Data Guard允许定义3种数据库保护模式，分别是最大保护、最大可用、最大性能模式。
这3种模式的区别在于，当主库发生故障时，备库的数据会和主库有多大的差距。