Oracle 11g Data Guard (ADG) 原理

下图为一个ADG的模型，那么这篇文章就来研究图中的箭头的原理，也就是日志是如何发送的

图中，主库在运行时会不断产生redo log，这些日志会通过网络传送到备库，这个传送动作，可以由ARCH完成，也可以由LGWR完成，选用哪种进程，对数据库的可用性和DG的保护能力有着很大的区别。

1.使用ARCH进程传送日志

主库不断的产生redo log，这些日志被LGWR写进联机日志，当一组联机日志被写满，会发生日志切换，并且ARCH会将其归档，本地归档是LOG_ARCHIVE_DEST_1='LOCATION=/...'这种参数定义，ARCH进程还会通过网络把归档日志传送给备库的一个叫做RFS的进程，备库接受日志并写入到归档日志，然后备库的MRP进程（redo apply）或者LSP进程（SQL apply）在备库上应用这些日志，于是数据就同步了。

使用ARCH传递的问题也是很明显的，只有日志切换作为前提，才能传送日志，如果主库异常停机，联机日志丢失，导致无法归档，那么丢失数据是在所难免！

在默认情况下，主库就是用ARCH进程传送日志，不需要特别的设置。

2.使用LGWR进程传送日志

LGWR又分为SYNC（同步）和ASYNC（异步）两种方式

2.1LGWR进程的SYNC方式

主库产生redo log要同时写入到日志文件和网络，即LGWR把日志写到本地联机日志文件的同时，还发送给本地的LNSN进程（Network Server Process），然后LNSN进程把日志内容通过网络发送到备库。

LGWR必须等待写入本地联机日志和LNSN进程传送成功，主库的事物才能提交，这就是实时同步的原理。

备库的RFS进程把接收到的日志立刻写入standby redo log中，所以在备库上看，最后一个日志总是IN-MEMORY,这也是我当初疑惑的一个问题，现在终于清晰！

备库的恢复方式可以是实时恢复，也可以是完成对standby redo log的归档后恢复。

另外NET_TIMEOUT参数单位为秒，作用是该段时间网络无响应，LGWR会抛出错误

LOG_ARCHIVE_DEST_2=‘SERVICE=ST LGWR SYNC NET_TIMEOUT=30'

2.2使用LGWR进程的ASYNC方式

使用LGWR SYNC方式也有弱点，如果在发送给standby db过程中出错，LGWR会报错，主库事物无法完成，

主库LGWR过分依赖网络状态，如果网络不能保证365天高速无悬念和不会被挖掘机挖断光纤，或者对数据同步不苛刻，也可以采用LGWR ASYNC方式。

主库产生redo log之后，LGWR-->LNSN，但是LGWR只需要成功写入日志文件，事物即可允许提交，不必等待LNSN进程传送成功。

主库联机日志写满后，归档，也会触发备库的standby redo log归档，然后触发MRP活LSP进程恢复归档。

即备库的恢复方式，只能是完成对standby redo log的归档后恢复。

由于LSWR不会等待LNSN，所以无需配置NET_TIMEOUT参数。

1.关于Data Guard日志接收的总结：

 备库的RFS进程接收到日志后，就把日志写到standby redo log或者archived log file文件中。

 而归档日志会被放在什么位置取决于standby database归档路径的选择，

 如果配置了standby_archive_dest,则使用这个参数指定的目录；

 如果配置了log_archive_dest_n，该参数明确定义了VALID_FOR=(STANDBY_LOGFILE,*)，则使用这个参数指定的目录；

 如果数据库的COMPATIBLE参数大于等于10，则选取任意一个LOG_ARCHIVE_DEST_n的值；

 如果standby_archive_dest和log_archive_dest_n参数都没有配置，使用缺省的standby_archive_dest参数，这个缺省值是$​ ​Oracle​​_HOME/dbs/arch。

2.关于Data Guard日志应用的总结：

 日志应用服务，就是在备库上重演主库的日志，从而实现两个数据库的数据同步。

 根据备库重演日志的方式不同，可分为物理和逻辑两种类型。

 物理使用的media recovery技术，在数据块级别进行恢复。这种方式没有数据类型的限制，可以保证两个数据库完全一致。

 而逻辑使用的logminer技术，通过把日志内容还原成SQL语句，然后SQL引擎执行这些语句。

 根据redo apply发生的时间可以分为2种：

 一种是实时应用，这种方式必须有standby redo log，每当日志被写入standby redo log时，就会触发恢复，

 使用这种方式的好处就在于可以减少数据库切换的时间，因为切换时间主要用在剩余日志的内容恢复上。

 另一种是归档时应用，这种方式在主库发生日志切换之后，才触发备库的归档，归档完成后再触发恢复，这也是默认的方式。

 如果是物理备库，可以使用下面命令启用real-time

 alter database recover managed standby database using current logfile;

如果是逻辑备库，可以使用下面命令启用real-time

 alter database start logical standby apply immediate;

查看是否使用了real-time

 select recovery_mode from v$archive_dest_status;

3.关于Data Guard环境中的重要进程的总结：

 主库：

LGWR：在主库上，这个进程负责吧redo buffer中的内容写入online redo log。

LNS（logwriter network service）：LNS进程读取日志，并通过网络发送给备库，这个进程的目的是为了给LGWR减轻负担，LGWR进程不用再参与到网络日志的传送中。

ARCH：归档进程，在主库中可有30个归档进程，其中有一个是专门负责本地归档的，不参与Gap Resolution,

而其他的arch进程都可以进行Gap Resolution。

 备库

RFS（remote file server）：这个进程负责接收网络上传来的redo日志，并把这些日志写到standby redo log文件中。

ARCH：同样是归档进程，只是在备库上，需要归档的是standby redo log文件的内容。

MRP（magaged recovery process）：这个进程负责协调介质恢复管理工作，整个物理备库就是建立在介质恢复技术上的。

PR0x（Parallel Recover Process）：这是进行具体恢复工作的进程，如果是real-time apply模式下，这些进程会从standby redo log文件中读日志；而在其他模式下，是从归档日志中读取日志然后再进行日志应用。

LSP（logical standby process）：这个进程在logical standby中才有，功能和物理备库的MRP进程类似，负责协调SQL APPLY过程。

1.关于standby redo log的理解

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状态。

2.关于Data Guard保护模式的学习和总结

 数据保护模式是指备库和主库之间数据同步程度。

Data Guard允许定义3种数据库保护模式，分别是最大保护、最大可用、最大性能模式。

 这3种模式的区别在于，当主库发生故障时，备库的数据会和主库有多大的差距。

1.最大保护模式 Maximum Protection

顾名思义，这是最高的数据保护级别，这个模式的规则是即便牺牲主库的可用性，也要保证不出现数据丢失！

 这个级别保证备库和主库的数据是完全同步的，即使主库突然夯机，在备库上也不会出现任何数据丢失。

 这种方式要求备库必须配置SRL，而主库必须使用LGWR、SYNC、AFFIRM方式归档到备库，并且用命令定义为最大保护模式。

 在这种模式下，主库上的每个事务的REDO日志必须在和本地和备库上都写入日志文件后才允许提交。如果不能写入到备库，

 主库就会自动关闭以方式数据丢失。但也不是立刻shutdown abort，而是不再生成任何REDO，并且不断地尝试连接备库，

 这个尝试大约最多会有10分钟，因为这一段时间内LGWR不再生成任何REDO，因此整个数据库表现为挂起。

 在这种模式下，至少要有一个备库是正常的，主库才能正常打开，否则主库都无法打开。

 如果主库是RAC环境，如果一个实例和备库之间网络发生了问题，那么在最大保护模式下，这个实例是crash，继而触发其他实例的crash recovery，

 完成这个recovery之后，Data Guard会忽略这个实例，而主库其他实例也能继续处理业务，并发送日志进行同步。除非所有实例连接备库都出现了问题，

 才会出现所有实例crash，最终导致整个数据库的crash。

2.最大可用模式 Maximum Availability

这是另外一种能实现零数据丢失的数据保护方案。这种模式需要至少有一个备库是通过SYNC和AFFIRM方式传送数据，并且要使用SRL文件才行。

 在这种模式下，主库发送redo日志、并等待备库确认，备库收到redo日志，记录到SRL中，并返回确认给主库，这时，主库上的事务才能结束。

 这是和最大保护模式一样的地方。因此，网络状态、备库的状态都会影响主库的事务性能。等待确认的时间用一个参数NET_TIMEOUT定义。

 如果主库在该段时间（默认30秒）没有收到任何反馈信息，这个备库就会被标记成failed，LGWR会继续写日志，但是会忽略掉这个failed的备库。

 如果在NET_TIMEOUT内收到了standby failed的消息，LGWR和LNS还会继续尝试重新连接，直到最终放弃这个备库为止。

 一旦备库被认为是failed，那么主库就会强制进行一次日志切换，以明确的标识出发生failed的时间点，也就是达到零数据丢失的时间点，

 而在这以后产生的redo日志就不再向备库发送了。

 在这以后的时刻，Data Guard的保护模式就降到了Unprotected了，如果是一主多备环境，会有其他备库保持同步。一致到解决了日志Gap，

 主库才会继续发送REDO，Data Guard才会恢复到Maximum Availability模式。

 在RAC环境下，如果一个实例认为备库是failed，则自动触发的日志切换会导致所有的实例都停止发送REDO，即便其他实例能够连接到备库。

 接下来，实例的ARCH进程还继续利用ping机制检测到备库的连通性，一旦恢复连接，则所有的实例会自动去解决gap，

 接着所有的实例会进行日志切换，以启动LNS进程，继续发送REDO。

 这种模式只是尽量避免数据丢失，也并不能保证数据完全一致。这种模式要求备库必须配置SRL，而主库必须使用LGWR、SYNC、AFFIRM方式归档。

3.最大性能模式 Maximum Performance

这个模式是默认的模式，它更加侧重对主库可用性不造成任何影响，即“在不影响主库性能的情况下，尽可能少的数据丢失。”

主库上的事务的REDO日志只要写到本地日志文件就可以提交，不必等待到备库传递完成。主库的REDO可以异步发送到备库。

 备库的任何故障，以及两者之间的网络故障都不会影响主库的活动，即便网络出现问题，主库也只不过暂时停止REDO传送，

 并等待ARCH进程通过PING机制发现连接恢复之后，继续重传。

 这种模式可以使用LGWR ASYNC或者ARCH实现，备库也不要求使用SRL。

 如果主库是RAC，并且工作在最大性能模式下，如果只是RAC的某个实例和备库的日志传递发生故障，那么也只有该实例的日志传递被中止。

 而其他实例的日志传递仍然继续。发生中断的实例上的ARCH进程会不断地通过ping机制来检查连通性，一旦发现连接恢复，这个实例上的gap会自动发送给备库，

 但是LGWR进程却并不会立即启动LNS进程去发送当前的redo数据，而是直到下一次日志切换时，LGWR才会启动LNS，开始传递REDO数据。

3.定义数据保护模式

 保护模式是针对主库进行设置的，这个设置是告诉主库必须要遵守的规则。对备库没有作用。

 数据保护模式在定义数据保护级别的同时，捎带着也同时定义了两个重要信息：

 主库如何向备库传送redo；

 当备库发生故障或网络出现故障，主库应该怎么做。

 以下命令都是在主库下执行：

ALTER DATABASE SET STANDBY TO MAXIMIZE PERFORMANCE;

 ALTER DATABASE SET STANDBY TO MAXIMIZE AVAILABILITY;

 ALTER DATABASE SET STANDBY TO MAXIMIZE PROTECTION;

切换模式的过程，先尝试能够在open状态下切换，不能的话，就在mount下切换。

shutdown immeidate

 startup

 alter database set standby to maximize availability;

 alter database open;

 select protection_mode,protection_level from v$database;