Data Guard的架构
Table of Contents
概述
Primary Database主库
处于open状态对外提供服务，用户在Primary Database 上进行操作，操作被记录在联机日志和归
档日志中。
需要设置 logging force 模式：
即使在归档模式下，也可能会有一些有nologging的操作不产生redo，这在DG下是不允许的，因此
必须启用数据库强制记录redo。
Standby Database备库
处于恢复状态，接收并应用主库传递过来的日志。
概述
DG的运行遵循一个很简单的原则：主库将redo日志传给备库，备库接受后验证并应用redo日志
-
DG只传输恢复数据库事务所需的redo日志，以便同步备库和对应的主库
- redo由redo entries组成，一个redo entry由一组变更向量构成，每个向量描述数据库中的一个数据块的变更
- redo entry : redo entry包含重新生成数据库更改所需的所有信息，例如雇员表中的薪水值
- 变更向量：撤销段数据块的变化、撤销段的事务表的变化以及表的数据段块的变化
-
DG会在备库应用redo日志之前执行Oracle验证，以免扩散主库中的受损的数据
-
如果网络中断或者备库断电导致主备库的连接临时中断，DG会自动使用在主库上已经归档的redo日志重新同步备库
① 生成redo时，redo传输服务将redo日志从主库传到备库
② 应用服务验证redo日志并更新备库数据库文件
③ 独立于DG，DBWn进程更新数据库文件
④ 在网络中断或备库停运后，DG使用已在主库上归档的redo日志，自动重新同步备库
传输方式
Redo Transport Service
Redo Transport Service主要协调从主库到备库的redo传输过程
主要传输过程：
- 主库的LGWR进程将redo从SGA的redo log buffer中写入到online redo log中
- 主库的LNS(Log Network Service)进程从SGA的redo log buffer中读取数据，并交由Oracle Net服务传输到备库的RFS进程
- 备库的RFS(Remote File Server)进程接受LNS传输的redo日志，然后将其写入standby redo log文件的顺序文件中
同步传输SYNC
同步传输(synchronous transport, SYNC)又称为“零数据损失”，使用同步传输可以使主库与备库随时处于同步状态，传输过程中主库要等到事务恢复所需的redo已被写入备库的磁盘里，才允许LGWR认可提交操作成功，具体的传输过程如下：
① 用户提交事务，事务再SGA中创建一个redo entry。LGWR从redo log buffer中读取redo entry，写入online redo log，并等待LNS的确认
② LNS从redo log buffer中读取相同的redo entry，通过Oracle Net服务传给备库。备库上的RFS接受redo，然后将其写入备库的redo log中
③ 备库的RFS从磁盘接受到写完的消息，会传回一个确认消息给主库的LNS，LNS接着通知LGWR传输完成。LGWR向用户发送确认信息
同步传输的不足：
SYNC可以确保得到数据库提交确认的每个事务都得到保护，但这种方式会对主库的性能造成影响。主要的原因就是：LGWR只有等到数据已在备库受到保护的确认消息后，才能才是继续处理下一个事务
redo log的大小、可用的网络宽带、往返网络延迟（RTT）以及备库写入standby redo log的I/O性能都会对应用程序响应速度和数据库吞吐量。所以网络RTT随着距离的延长而增加，主库的性能也就会受到影响，实际上则会对主库与备库之间的距离形成限制
异步传输ASYNC
异步传输(asynchronous transport, ASYNC)与SYNC的最大的不同就在于LGWR不用等待来自LNS的确认消息，无论主备库之间相距多远，都可以做到几乎不影响主库的性能
即使由于宽带有限，使得redo不能立即传给备库，LGWR也将继续确认提交操作成功完成。如果LNS赶不上LGWR的提交进度，主库在LNS将redo传给备库前就回收了redo log buffer，LNS将自行转为从online redo log 读取和发送redo；当LGWR赶上进度后，将自行转回直接从redo log buffer中读取发送
① 用户提交事务，事务再SGA中创建一个redo entry。LGWR从redo log buffer中读取redo entry，写入online redo log，并向用户发送确认信息
② LNS从redo log buffer中读取相同的redo entry，通过Oracle Net服务传给备库。备库上的RFS接受redo，然后将其写入备库的redo log中
③ 主备库之间的日志传输出现异常等情况时，LNS自动转为从online redo log读取和发送redo；恢复后自动转回从redo log buffer中读取和发送redo
异步传输的不足：
ASYNC最大的不足就在于增加了数据丢失风险。如果某个故障破坏了主库，而此时传输滞后尚未降低到0，那么传输滞后所包含的任何已提交事务都将丢失。所以在使用ASYNC时，提供足够打的网络宽带来处理峰值期间告诉产生的redo，可以最大限度地降低数据损失的风险
应用服务
DG提供了两种不同的方式在备库中应用redo：Redo Apply（物理备用）和sql apply（逻辑备用）
DG的宗旨是防止丢失数据，设计目标是让备库成为主库的同步副本。DG的设计纯粹的是为了实现对整个数据库的单向复制。因此，DG还嵌入了safeguard，以免在备库上对主库是上复制来的数据进行任何未授权的改动
DG的第二目标旨在高度分离主库和备库，以防主库上发生的问题影响到备库，进而危及数据的保护和可用性，这样做也可以防止备库上出现的问题影响到主库的可用性或性能
DG的第三目标是在主库出现故障时提供数据可用性和高可用性。**Redo Apply和sql apply都能将一个同步备库快速的转成主角色。**这样可以主库出现计划内或计划外中断后保护数据和恢复可用性
DG的最后一个目标是为备用系统、存储和软件投资提供高额回报，而不会影响“数据保护和可用性”这项重要使命。Redo Apply和sql apply都允许将仍担当备用角色的备库投入生产，同时不影响数据保护或实现恢复时间目标（recovery time objectives）的能力
Redo Apply
Redo Apply维护的备库是与主库逐块对应的精确的物理副本
当备库上的RFS进程收到从主库传来的redo，然后将其写入standby redo log时，Redo Apply使用戒指恢复将standby redo log中的redo entry写入内存，接着直接在备库上应用更改。
介质恢复包括一个MRP进程以及多个并行应用进程（pr0x）
MRP管理恢复会话，按照SCN顺序合并来自多个实例的redo（在使用RAC主实例的情形下）然后将redo解析到按应用进程划分的更改映射中。应用进程读取数据块，组装映射中的重做更改，然后将重做更改应用于数据块。Redo Apply将应用进程数量自动配置为比备库系统中的CPU数量少1。
Oracle针对Data Gurad Redo Apply的基准测试表明，在承担OLTP（联机事务处理）工作负荷时其速度高达47MB/s，在直接路径加载情形下速度高达112MB/s
Redo Apply可防止将主库上的物理损坏应用到备库，从而提供了卓越的保护能力。以SYNC或ASYNC模式直接从SGA传输的redo与主站点上的组件故障造成的物理I/O损坏完全隔离
当备库使用Redo Apply应用redo时，将读取相应的数据块，并将SCN（对应刚从主库中传过来的redo的SCN，主库的SCN）与redo log中的SCN（保存在备库的redo log中的SCN，备库的SCN）进行比较，可能出现的比较结果如下：
- 主备库相同：说明主备库数据同步正常
- 主库的数据块SCN小于备库的数据块SCN：说明主库出现了写丢失，此时回报错ORA-752，建议的响应操作是执行到物理备库的故障转移，然后重建主库
- 主库的数据块SCN大于备库的数据块SCN：说明备库出现了写丢失，此时回发生内部错误ORA-600 3020。如有可能，需要使用受影响的数据文件在主库的备份来修复备库；否则，必须重建备库。
Sql Apply
Sql Apply（逻辑备库）使用逻辑备用进程（LSP）将更改协调应用于备库。
DG 转换日志文件中的数据为SQL语句在逻辑standby上执行SQL语句，因为逻辑standby是通过SQL语句来实现数据同步，所以在同步期间其必须保持打开状态。
保护模式
DG的三种保护模式
DG相关的进程
Log Transport Service
在主节点上，日志传输服务主要使用如下几个进程：
- LGWR
LGWR写联机重做日志
在同步模式下，直接将redo信息直接传送到备库中的RFS进程，主库在继续进行处理前需要等待备库的确认在非同步情况下, 直接将日志信息传递到备库的RFS进程，但是不等待备库的确认信息主库进程可以继续进行处理。 - ARCH
ARCH进程可以在归档的同时，传递日志流到备库的RFS进程，该进程还用于检测和解决备库的日志不连续问题（GAP）。 - FAL：(Fetch Archive Log)
fetch archive log只有物理备库才有该进程，FAL进程提供了一个client/server的机制，用来解决检测在生产库产生的连续的归档日志，而在备库接受的归档日志不连续的问题，该进程只有在需要的时候才会启动，而工作完成后就关闭，因此在正常情况下，该进程无法看到，可以设置通过LGWR，ARCH进程去传递日志到备库，但是不能两个进程同时传送。 - LNSn（LGWR Network Server process）
把日志通过网络发送给远程的目的地，每个远程目的地对应一个LNS进程，多个LNS进程能够并行工作。
Log Apply Service
在备库节点上，日志应用进程主要使用如下的进程：
- RFS （Remote File Server）
RFS进程主要用来接受从主库传送过来的日志信息
对于物理备用数据库而言:
可以直接将日志写进备用重做日志
可以直接将日志信息写到归档日志
为了使用备库重做日志，必须创建备用重做日志，一般和主库的联机日志大小一样, 组比主库多一组 - ARCH
只对物理备库，arch进程归档备库重做日志，这些日志以后将被MRP进程应用到备库。 - MRP：(Managed Recovery Process)
该进程只针对物理备库，该进程应用归档日志到备库，如果我们使用sql语句启用该进程 ALTERDATABASE RECOVER MANAGED STANDBY DATABASE , 那么前台进程将会做恢复，如果加上 disconnect 语句，那么恢复进程将在后台进行，发出该语句的进程可以继续做其他的事情实现
