GoldenGate同步过程中的长事务处理

关系型数据库在日常运行中，不可避免会用到事务，而RDBMS与NoSQL的一个主要区别就是事务支持粒度;同时，事务也是保证数据一致性的主要手段。在使用GoldenGate进行数据同步时，对事务的管理，特别是长事务的管理，是日常运维工作中的一项重点。

长事务的产生有多种可能，比如一个SQL语句处理的数据量过大，如果系统资源不足，作业执行可能长达数小时以上;又或者在一个事务中，多次循环、分批次执行多个SQL语句，而只在事务的最后才提交

又或者用户在其终端上通过数据库客户端修改了数据，但是一直未提交，也未回退，且该客户的电脑一直未关机，这种事务持续时间可达数天或数月。虽然某些事务对生产系统影响不大，但GoldenGate为了保证数据同步中的完整性，对事务所在的日志文件有一定要求。

长事务如果一直未提交，在使用GoldenGate初始化或数据泵导出存量数据时，该事务修改的数据将无法导出到目标库;而启动增量捕获时，GoldenGate只会从进程添加(或register)那一刻开始解析日志，当前未提交的事务不会被捕获。另外，在日常同步中，长事务会占用更多的内存资源，且对日志的保留时间也有更高要求。

所以，在采用GoldenGate进行数据同步的环境中，有必要对长事务进行监控及管理;如果对业务系统中执行的SQL非常了解，且都是短平快的事务，则可以不用特别考虑长事务的影响。

BR原理

在了解GoldenGate如何管理长事务之前，我们先了解GoldenGate在抽取增量时的一个功能特性：

基于边界的恢复(BoundedRecovery，简称BR)。

为了更快的恢复GoldenGate的抽取过程，GoldenGate在重新启动后，默认不会从未提交事务的开始时间点读取日志(视事务的运行时长而定)，而会根据本地暂存的数据和最后一次保存点(BR)开始读取。

基于BR的恢复，是常规Extract(抽取进程)检查点机制的一部分。

它可以确保Extract在任何原因(计划的或计划外的)停止之后，无论Extract停止时有多少未提交事务，以及它们有多“旧”，抽取进程都可以有效地恢复这些事务。

我们来看一个示例图：

BR在9点开始，默认每4小时执行Checkpoint(13点、17点…)，但抽取进程在16:50停止，所以17点的BRcheckpoint实际并没有发生;

基于BR的处理逻辑，第一次13点checkpoint时，由于T3,T4未执行超过4小时，所以不会被checkpoint写入磁盘;而T1、T5由于事务已经超过4小时，所以缓存在内存中的事务数据及状态会写入磁盘;

在16:50停止抽取进程exa时，各事务的处理逻辑如下：

T1，T3在15:00已经提交，不会受到影响;

因为T2执行时间未超过4小时，所以缓存在内存中的数据会被丢弃，不会保存到磁盘，所以exa重启后，T2的日志读取点仍然是事务开始时间13:15;

基于相同的原因，T4缓存在内存中的数据也会被丢弃，由于一直未得到checkpoint机会，所以抽取进程会从事务的开始时间(9:10)开始解析日志;

最后，T5因为在13:00做过一次checkpoint，所以抽取进程下次启动时，不会再从头解析此事务的日志，而是读取磁盘上的BR数据后，从13点开始解析该事务的日志。

从上图可以看出，使用了BR技术之后，数据库理论上只需要保留最近8小时的日志(图中T4事务);但如果BR恢复失败(如参数文件有修改或其它原因无法使用BR恢复)，则GoldenGate会使用普通的恢复模式，此时，需要从最早未提交事务的开始时间点重新解析日志，一般情况下，可能需要不止8小时的日志;

GoldenGate在21:00重启后，会先基于BR保存的checkpoint数据进行恢复，再结合日志进行抽取，其间已提交的事务因为已处理而直接跳过，不用再做处理，从而提升GoldenGate抽取进程的效率;

官方手册上，不建议修改BRcheckpoint的间隔时间，因为超过4小时的事务一般都是长事务。

在GoldenGate中查看BR恢复点

在了解了BR的原理之后，我们来看一下在GoldenGate中如何查看一个具体的BR恢复点。

通过如下命令，可查看GoldenGate抽取进程对应的BR检查点。

长事务检测

通过对BR原理的了解和查看，我们现在来看在GoldenGate中如何检测和监测长事务，一般有两种方式。

方法一、在GGSCI命令行中查看

查看20分钟以上的长事务，但未找到符合条件的事务。

需要指出的是，即使有长事务，也不意味着GoldenGate有很大的延迟，如果GoldenGate有足够的资源缓存long-trans，抽取进程仍然会读取和解析当前的redo log，所以实际的lag会很小。

方法二、配置GoldenGate抽取参数

通过在抽取进程中配置监控参数，当有符合条件的长事务时，则会在日志文件中输出告警日志。

当有符合条件的长事务时，会在日志文件中生成相应的告警信息：

长事务的处理

针对前面的BR原理和长事务的监测，为了确保GoldenGate的同步不会因为事务超长而造成归档日志积压太多，可以通过以下方式解决。

在GoldenGate中跳过长事务

如果确认抽取的表不在长事务中，则可以在GoldenGate命令行手工跳过。

针对上面GoldenGate查到的长事务，可执行以下命令跳过。

再次查看，在GoldenGate中已经看不到刚才的事务。

需要注意的是，上述语句只是在GoldenGate中跳过了对该事务的解析，而对该事务的执行没有任何改变，即该事务在数据库上所占用的资源不会产生任何影响。

数据库中处理长事务

基于GoldenGate showtrans的结果：

可根据上述返回的XID值，在源库中查询事务对应的信息，包括机器名、IP、执行SQL语句、SID等，以帮助DBA进一步判断分析，或通过kill语句杀掉不需要的事务。

也可以根据返回的sid/serial#，在数据库上kill掉对应的事务：

格式如下：

不过在执行kill命令之前，一定要确保了解这个操作的影响，特别是在生产环境，需要慎之又慎。