Oracle GoldenGate 系列：Extract 进程的恢复原理

Extract 进程恢复原理

BR

适用于 Extract 进程（仅适用于 Oracle数据库）

使用 BR 参数可以控制 GoldenGate 的 Bounded Recovery (BR) 功能。Bounded Recovery 功能仅支持 Oracle 数据库。Bounded Recovery 是通用 Extract 检查点工具的组件之一，可以保证当Extract 进程出于任何原因（计划停机或意外停机）停止后，无论在进程停止时的时间点上存在多少个未提交的事务还是这些事务持续的时间多么久，Extract 进程都能进行高效地恢复。

Bounded Recovery 为 Extract 进程恢复到停止的时间点然后恢复正常处理所花的时间设定了一个时间上限。

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

 

Extract 进程如何恢复未提交的事务

当 Extract 进程在 redo log 中遇到某个事务的起点（在 Oracle 中通常为第一个可执行的 sql 语句）时，便会将从该事务中捕获到的所有数据缓存到内存中。即使开始该事务不包含任何数据，

 Extract 进程也必须将事务缓存到内存中，因为该事务中后面的操作可能包含要捕获的数据。

 

当Extract 进程在 redolog 中遇到事务的 commit 记录，便会将缓存在内存中的整个事务写入trail 文件，并将其从内存中清除。当 Extract 进程遇到事务的  rollback 记录时，便会丢弃缓存中缓存的整个事务。在 Extract 进程处理 commit 或 rollback 记录之前，都会视事务为

Open状态（未提交或回滚的），并持续不断地收集该事务的信息。

如果 Extract 在遇到事务的 commit 或 rollback 记录之前停止，则在 Extract 进程重启后，必须对所有缓存在内存中的信息进行恢复。此操作适用于 Extract 进程停止时所有处于 open 状态的事务。

Extract 按照如下方式执行此恢复过程：

● 如果在 Extract 进程停止时，不存在处于 open 状态的事务，则恢复操作从当前的

Extract 读取检查点开始，这是正常的恢复过程。

如果 redo log 中存在起始点非常接近于 Extract 进程停止时间点的 open事务，则 Extract进程会重新读入 redolog，从其中最早的 open 事务的起始点开始恢复。此过程需要 Extract 进程对该进程停止前已经写入 trail 或 discarded 文件的事务执行额外的工作，这一重复的工作只需要处理相对较少的数据，属于可接受的成本范围内。这种恢复也可视为正常恢复。

 

● 如果存在一个或多个 Extract 进程视为长时间运行的 open 事务，

 则 Extract 进程便会通过 BoundedRecovery 进行恢复。

 

Bounded Recovery 的工作原理

如果事务处于 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 操作类似），可以避免上述的额外重复工作。

 

Bounded Recovery 示例

下图显示的时间轴上，随着时间的推进，一系列的事务开始处理。该图清晰地演示了长时间运行的事务如何以特定的时间间隔持久化（写入或存留）到磁盘，然后在发生故障后进行恢复，它可以帮助我们理解本例中所使用的相关术语：

 

●持久化对象是指缓存中已在 Bounded Recovery 检查点过程中持久化的任何对象。通常情况下，此对象就是事务的状态或数据，不过缓存中还应包含一些Extract 进程专用对象。这些对象统称为持久化对象。

● 最早的非持久化对象是指当前 Bounded Recovery 检查点之前最近的一个 BR 间隔内，缓存中最早的 open对象。通常情况下，该对象就是该时间间隔内最早的 open 事务。Bounded Recovery 重新开始时，运行时处理就是从最早的非持久化对象的起始位置开始恢复的，在一般的事务处理中，该位置就是该事务在 redo log 中的起始位置。

 

在本例中，Bounded Recovery 间隔为4小时。如果 open 事务开始的时间点距离当前的 Bounded Recovery 检查点超过一个 Bounded Recovery 间隔，则该事务就会在当前的 Bounded Recovery 检查点被持久化。

在 BR 检查点 n 处:

● 有 5 个处于 open 状态的事务： T(27), T(45), T(801), T(950), T(1024)。所有其他的事务均已提交或回滚。这些事务都从其起始点开始延时间轴不断运行。

●运行的时间超过一个 Bounded Recovery 间隔的事务有：T(27) 和 T(45)，在BR 检查点 n 处，这些事务都会被持久化（写入）磁盘。

●最早的非持久化对象是 T(801)。该事务不符合持久化到磁盘的条件，因为其运行的时间还没有超过一个 Bounded Recovery 间隔。作为最早的非持久化对象，T(801) 在日志中的起点位置存储在BR 检查点 n的检查点文件中。如果 Extract 进程在 BR 检查点 n 之后意外停止，则该进程将恢复到该日志位置，然后才能重新开始读取解析日志的内容。如果在BR 检查点 n之前的 BoundedRecovery 间隔中没有最早的非持久化的对象，则 Extract 进程就会从当前 Bounded Recovery 检查点的日志位置重新开始读取日志。

 

在 BR 检查点 n+1 处：

● T(45) 在前一个BoundedRecovery间隔内已经变脏（发生过更新） ，因此该事务将写入到一个新的持久化对象文件中。旧的持久化对象文件将在 BR 检查点 n+1完成后删除。

● 如果 Extract 进程在写 BR 检查点 n+1时或在 BR 检查点 n 和 BR 检查点 n+1 之间的任意Bounded Recovery 检查点间隔内失败，则 Extract 进程将从上一个有效的 BR 检查点 n 开始进行恢复。BR 检查点 n重新开始的位置就是最早的非持久化事务T(801). 的起点。因此，在最坏情况下，Extract 进程的恢复停止的时间点所需的时间不会超过两个 Bounded Recovery 间隔，在本例中，恢复的最长时间不会超过 8 小时。

 

在 BR 检查点n+3000 处：

● 系统已经运行了很长时间了。T(27) 和 T(45) 是仅存的持久化事务。T(801) 和 T(950) 已在 BR Checkpoint n+2999 之前的某个时间点提交并写入trail文件。现在仅存的非持久化 open 事务为 T(208412) 和T(208863) 。

● BR Checkpoint n+3000已写完。

● 在 BRCheckpoint n+3000 之后的 BR 间隔内，发生了电源故障。

● 新 Extract 进程恢复到BRCheckpoint n+3000。 (27) 和 T(45) 从包含BRCheckpoint n 的状态的持久化检查点文件还原出来。日志读取从 T(208412) 的起点开始恢复。

转载请注明作者出处及原文链接：

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