oracle DG 原理及体系

DG基本原理是:

将日志文件从 原数据库 传输到 目标数据库，然后在目标数据库上应用这些日志文件，从而使目标数据库与源数据库保持同步，是一种数据库级别的高可用方案。

 

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，搞清楚了就好了

一个是归档进程

一个是重做日志

 

 不同的日志应用方式的详解：

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 传输到 灾备数据库

 

既解决了性能问题，又解决了数据安全问题