Bounded Recovery

首先，我们来看两个OGG同步中可能的问题：

l oracle在线日志包含已提交的和未提交的事务，但OGG只会将已提交的事务写入到队列文件。因此，针对未提交的事务，特别是未提交的长事务，OGG会怎样处理呢？ 

当 Extract 进程在 redo log 中遇到某个事务的起点（在 Oracle 中通常为第一个可执行的 sql 语句）时，便会将从该事务中捕获到的所有数据缓存到内存中。即使开始该事务不包含任何数据，Extract 进程也必须将事务缓存到内存中，因为该事务中后面的操作可能包含要捕获的数据。当Extract 进程在 redolog 中遇到事务的 commit 记录，便会将缓存在内存中的整个事务写入trail 文件，并将其从内存中清除。当 Extract 进程遇到事务的  rollback 记录时，便会丢弃缓存中缓存的整个事务。在 Extract 进程处理 commit 或 rollback 记录之前，都会视事务为Open状态（未提交或回滚的），并持续不断地收集该事务的信息。

如果 Extract 在遇到事务的 commit 或 rollback 记录之前停止，则在 Extract 进程重启后，必须对所有缓存在内存中的信息进行恢复，重新从规定日志中抽取长事物的信息，那么这个恢复时间就会比较长。

l 有些长事务是在批处理作业中，需要几个小时才能执行完成，比如晚上跑批的作业。OGG在解析过程中，会从这些事务一执行就开始读取在线日志，但这些事务可能会持续很久，在期间，在线日志可能会切换到归档日志，同时这期间也会有其它事务在执行和提交，如果长事务一直未提交，归档日志又因为定期的rman备份而删除，OGG将如何处理？

针对以上情况，OGG有2种处理方式，

第一种就是使用正常恢复归档的方式，即恢复OGG需要的所有归档日志，可能是从长事务开始的那个归档开始，这样OGG将从事务开始的检查点开始解析；

第二种方式就是使用Bounded Recovery的方式，下面的内容将讨论这种方式。

简单来说，BR（Bounded Recovery ）默认的设置是4小时，即每4小时OGG抽取进程会做一个检查点，在每个检查点的时间点上，OGG会检查长事务，并将超过4小时的长事务的状态写入到磁盘（如果没有达到4小时，则此事务不会被BR写入），默认保存在OGG安装目录的BR目录下。在每个BR的间隔点，这个操作会一直持续，直到事务提交，或事务回滚。

Bounded Recovery可以保证当Extract 进程出于任何原因（计划停机或意外停机）停止后，无论在进程停止时的时间点上存在多少个未提交的事务还是这些事务持续的时间多么久，Extract 进程都能进行高效地恢复。

注意 在将此参数修改为默认设置以外的其他设置时，请联系 Oracle Support 获取指导。大多数生产环境无需修改此参数。 

设置BRINTERVAL为20分钟：

BR BRINTERVAL 20M

Use the BR parameter to control the Bounded Recovery (BR) feature. This feature currentlysupports Oracle databases

Bounded Recovery 的工作原理

在 Extract 进程处理 commit 或 rollback 记录之前，都会视事务为Open状态（未提交或回滚的）,如果事务处于 open 状态的时间超过 BR 参数的 BRINTERVAL选项中指定的Bounded Recovery 间隔，则 OGG 就视该事务为长时间运行的 open 事务。例如，如果 Bounded Recovery 间隔为4小时，则任何持续时间超过4小时的事务都可视为长时间运行的 open 事务。每隔一个 Bounded Recovery 间隔，Extract 都会进行一次Bounded Recovery 检查点操作，该检查点操作会将 Extract 进程的当前状态和数据写入磁盘，包括任何存在的长时间运行的事务的状态和数据。如果 Extract 进程在一个Bounded Recovery检查点之后停止，则该进程将从上一个Bounded Recovery间隔点或上一个BoundedRecovery 检查点位置进行恢复，而不会从 redo log 或 archived log 中最早的长时间运行 open 事务的起始位置开始进行恢复。

 

Bounded Recovery的最大时间 （Extract 恢复到停止时间点的最大时间）永远不会超过当前 Bounded Recovery 检查点间隔的 2 倍。实际的恢复时间将由如下因素决定：

● 从 Extract 进程停止开始到最后一个有效的 Bounded Recovery 间隔之间的时间。

●整个恢复期间 Extract 进程的处理情况。

●之前写入磁盘的事务的处理时间比。

Bounded Recovery 处理这些事务（丢弃这些事务）要比其在首次必须执行磁盘写入时要快很多。 大多数事务数据的重新处理都包含此过程。

当 Extract 进程进行恢复时，该进程会 restore 最后一个Bounded Recovery 检查点（包含任何长时间运行的事务）保存的数据和状态。

例如，如果一个事务处于 open 状态的时间有 24 小时，Bounded Recovery 间隔为 4 小时。在这种情况下，Extract  进程最长恢复时间不会超过 8 小时（<=4*2），可能会小于该时间。这取决于 Extract 进程停止的时间点和最后一个有效的 Bounded Recovery 检查点以及 Extract 进程在该期间的活动情况。

 

Bounded Recovery 解决的问题

利用磁盘的持久性来存储和恢复长时间运行的事务，这种情形很少发生，但是一旦发生，这一特性将显著地提高 Extract 进程执行恢复的性能。当 Extract 进程停止时其正在处理的长时间运行的事务在 redo log 中的起始位置通常都在一个非常早（距离当前时间非常久远）的位置。一个长时间运行的事务很可能跨越了大量的老旧的日志文件（online和archived log），这些比较早的日志文件，有些早已通过备份转移到其他的存储设备或者直接删除了。如果通过读取日志从长时间运行的事务在日志当中的起始位置开始进行恢复，则需要大量的时间成本，其实在数据库中长时间运行的事务时非常少的，在此过程中大部分的工作实际上是又捕获了一遍已经写入 trail 或

Discarded 文件的其他事务。利用 bounded recovery 可以 restore 磁盘上存留的长时间运行的事务信息（同 Oracle 数据库中的 restore 操作类似），可以避免上述的额外重复工作。

 

参考：

http://blog.csdn.net/xiangsir/article/details/8785484

http://www.cnblogs.com/margiex/p/4073081.html